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ABSTRACT 


This research focuses on the principles upon which 


modeis have been, and may be, constructed for estimating 


Ges= and effort in seftware development projects. A defini- 


mor, Of and Wieeeors 92 tluencin« software engineering 
economics is presén«ed. The major vhases and activities of 
mee SOLtWeare lifecycle are desctibed. Sitort, tine and cost 
eStinaztion is analyzed. MeO Sseme2t2 ON 2S “Hen “given oF 
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some widely used models for estimating cost and effort. 


Mer -iCal factors which must be considered when constructing 
peo G-i fOr eStimea-27g ¢€Ost and effort in software develen- 
ment prejects are then prasented. We SumMaE2 ZS by citina 
M@eees that EFegquire mors attention if cost and effor- esti- 
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A. BACKGROUND 


The history of software engineering is repiete wit 
tales of orojects that have never been comnoleted or hav 
meacnea completion only after numerous cost overruns and 

eil beyond the originaliy scheduled operational date. As 


the problems with software engineering became increasingly 


apparen=, researchers directed their attention to tinding 
Mewes tO MOre accurately predict the ccst, arrort “aad. fine 
ena t a software development project would Sea re 
Attention nas been dévoztsd +o determining sound estimates 
GemmedasltY aS pOSsibic in tha voroject. ieee ly Necets Wers 

DECLIic Eenviron- 


Geveloped to provide single estimates in sg 
men=s. “foders graduaiiszy evoived th 


a. 
-_ = Te qs SSR 7 7 “oagois rm “mt = a-iahj: 
CP ce eC Ce 6 Peete As SEN ava. (4 0. 


Be. PROBLEM 


miemeaoolem ceoebe addressed in this study is to fini 
miese shiluences that afrect estimates of cost and affor+ ir 
@ soitware development environment. The ch 
hat are identiried will not necessarily apply to all envi- 
ronments Dut must pe evaluated to determine whe 
Bem@eributors to cost, 2ffort and scheduling in 


fixe da tion. 





C. GENERAL PROCEDURE 


The procedure that has been used was to research litera- 
ire concerning cost and effort estimations in software 
develcpment projects. Information was gathered concerning 


some of the most widely used and successful piee a? 


ry 
t-'- 
ct 
iD 
4 
rw) 
ey 


models. We gathered from this research numerous c 


that must be considered py the estimator before implementing 
W 


any model that e¢sStimates ccst and 2£ffort in a sctt 


development vroject. We aiso noted inrtiuences on sotiwars 
Mme GCONENt PlOjJsc7tS cnat Have not yet been adequately 
mee sesseq in cost and effort estimating efrores. 


De. ORGANIZATION 


@ 
Q 
O 


BeecOrs a@a-recting softwar Ss 
then oresented by the authors of this research paper in hope 
that these will be addressed in developing a superior cost 


ad 


mma CLrcOLlt estimating model. 
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II. UNDERSTANDING 


= ell eo = = = SS See 


A. A DEFINITION OF SOFTWARE ENGINEERING ECONOMICS 


The term software engineering has been used extensively 


ByeOugnour literature to refer to the various stages of 
m z 


sofiware develooment and maintenance. Scitware now commands 
Meee jor pe== Of any bUGGet FOr a@ COMpUTEeE SySten. ieee 
mee 1950's Ba- Cl a Computer prejec='s budget was @evoted 
+0 hardware with «he rémaining 15% given tO scetftwars. 
Teday, these figures are reversed. fReE. 1: pe 41) The 
refinements and advances in hardware combined with the ever 
Mere es_ 2G costs Of Its production have turned focus on 
meee st= ARG 22S adzli«y to exploit= the system's innate 
BOeeTentlal. Themcomesctlal Ppromznance work Scitware in any 
computer system déemancs that wnenever we speak of software 

Si cuseNocCs G2 CUD tasks 
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Maintenance of scftware. 
That we are only now beginning to clearly undéerst 


3 
complexity of the software issue can be seer from <t«he 


Nhumercus failed attempts to forecast the cost and eifort of 
software development projects. Disas*rous software develop~ 
ment projects have motivated the development of numerous 


cost and effort estimating models that have met with varying 
degrees of success in accurately pr2adicting the course of a 
software development effort. Successful modeis have been 
used as foundations upon which even more accurate ancdesis 
have been déveloped. The majority of models that are avail- 
able to estimate cost and effort were developed by private 


companies to be used in their own working environment. 
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These modeis wher applied to other environments are unpre- 
Gictable and therefore or questionable value [Ref. 2:  p. 
116 j. We will exemine the most prominent of the numerous 
cost estimating models and evaluate their characteristics 
Gea applicability. We will seek to uncover the remaining 
problems that currently available cost and effort estimating 


models inadequately address cr compi2etely ignore. 


femwpeaqun by Gevelou:ng a definition of scftware endgi- 
neering economics through reviewin dere net2ors OO. theevern 
softwere engineering as offered by a nunber of ecrominent 
S@@evicials in the computer industry. The most comprehen- 
Sive work on software engineering 2conomics is a recently 
pte. shed text of the same title by Barry Bcehn. Bochm 
ee SO twee ™cmericsrimg as "...the application of 
Besemce and nethematics by Wereme he Capasizi= es of 
computer e2quipa 


poly S| Sate . ~ - = = 
ent are nade uséezul to man via conputec 
iS 


DooOgrams, procedures, and associated decumentation" [ Ref. 3: 
De 16 }. Peters enc @Eipp az tHe 3rd iInternationel 
Menteserce on SoOitware Engineering define software engi- 

; Speed eme > TSvasltonshics 


Meeeang by identifying tne concep a E 
Ufrece 2h a Study of soOnewats sngineering (Ref. 4: pp. 
63]. Remus of IBM's Santa Teresa Laboratory defines 
Mmepemengineering as "...the science of implementing giver 
Functionai and performance requiraments ina program 
Cptimum quality, at minimum cost, while meeting committed 
pencagles" (Ref. 55 p. 267}. Kerola and Freeman a 
International Conference on Software Engineering present 
SeeaWware engineering es "...the application of neéthods, 
tools and techniques to actions in a reliable and predict- 
able manner or {a) set of staced, technical, ecoromic ard 
Meee gCals for a software artifact" (Ref. 6: pe. 91}. We 
especially note tne reference to the sccial aspects of scit- 
ware engineerinag. iL een human aspects of software 


ie 
Smgeneercng are not taken into account as concerning both 


12 





miemcgevelopers ana she users, the software product will not 
Beaiize 2ts <itull potential. We define «he term software 
engineering economics as the art and science of utilizing 
analytical tecaniques, Managerial principles and common 
sense to arfectively and efficiently conclude the develop- 


Ment and maintenance of software at minimal cost. 


Be INFLUENCES ON SOFTWARE ENGINEERING ECONOMICS 


A number of metnods have been used to estinarte the 

Be pEOCTeCtS. Early 2stimates cf 

Project size ar2 not likely to be very accurate as the ex 

SG@eorOr ee Os cyeec =e are not conclusively known. 

zsimmons recommend sstimating the size of a 

Pl ieepeeyec. US2ng the laws of etatistics 

Din vacitne NC uaeng. the stand 
e. Edziy es<in 


a’ 
eepeetne availabdDie Zniornaticn the ds 
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Remo Gea uOne. ase ht.on 2S being given =o tne 
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etermination of the design and 
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project, estimators have an increa 


a 
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MieorMation to use. The increased effort being gi 
iront-erd development ofr a project will su 

decrease ~he finai cest and ezfort expended on a pr 
Meeeuse of better project preparation. Seauleclcc.. Gec 
Sition is used to mors clearly understand ard 3 
estimate the size cf a project by understanding and 
Mating «he size of seach segment of the projecc. DUEL ag <2ne 


development process, iterations of size estinations continue 


° 


Js 
ye) 
ct 


to improve che certainty of the size of «the project. 
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Accurately ¢stimating si 
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N 


= 


See Neuagor-OoS-acie ir esti- 


Mating the cost and effort required in software developmen: 


peo 7ECtS. 
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The following criteria have been 
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Petimating the size cf a software project: les 
code and executable instructions. A fairly recent develop- 
ment in complexity estimation developed by Halstead that 
Will be discussed later 2sserts that siz is a function of 
the vocabulary of a program. The vocabulary or the pregran 
is the sum of the operators and operands used. According to 
mas author, tenes Of Ogee, Lengih {Sun Cr she nunber of 
times opera*ors and cperands are use¢d) anda aveca SUT Sawears 
ali valid measures of ovorogram size. tes PrOoLlen WuTk 
lstead's and other technigues of size m2 q 


— ss 4 -_ ~- : =. 8 ~ ~ 
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Mee=S and *hs 
mes. Crivers, aS the sil 
humber of psople in E cS 
Signirticanzt new prorlems are created. Brocks léarned rro 
Mee «6©exXperience with =he Tem OS/360 project <zhaz nen 
months are not interchangeable. Using man-montks to an 
the size of a project is dangerous since men and months are 
Die i2n an environment where a job 
hed among workers and workers separatel 


Mmeem ech other <0 preclude communication. fee ea ie ye 
Seen ing and communication take up a significant amount of 
time in increasingly large projécts. Ret. 7: pps 13-26) 
And although time consuming, communication is essential for 
a successful project. Esterling's research also showed that 
project compietion time can be improved upen cnly up toa 
cértain point by adding personnel. Added personnei eventu- 


eeeey Serve only to delay the project. [Ref. 8: p. 168] 
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Software engineers use complexity to denote treat- 
ability, Vases naoLl Loy, Beadadtiaey and/or 
comprehensibility of a program [Ref. 9: pe 317]. Complexity 
plays an important part in two phases of a soctware life- 
eycles development and maintenance. PRE VGOnmmexi=y Of a 


Seogram Wiil directly infiuence the cost and effort in 


Sesting and debugging and in correcting bugs that subse- 
Beentiy SUETaCcSe fr5cm uss. Pre Osseo eye oe em = 7 iio + 
Meogram due =O changing requ Hetes ews lkeciso pe dl rectiv 
feeb acted to *he complexity of a pregranm. Complexity measures 
mayo CrOoMen difficult to objeczity in project cvaluations. 
mee Main problem witr both ze and complexity measures is 
M@emthey ate done arter the fact, i.¢., after the code has 
been written. A complexitv measur2= will be judged on its 


meer= ty tc predict ede Cason amece Wiel emesecat=ch in 


She ccmpisxity area impiiss that programmer performance can 
memorecaicied from the source code Of a progran. 

fie Guest or betpa  esk=sa today 2S which factors of 
the many researched in Progd@ens best Capture progran 
@eomplexity. Two other factors have shown to influence 
program complexity: the programmer and the programming 


cask. Significant individual differences have been found in 
programmer performance. UicemeamoOrcans Pownce here: 2s Tot 
meat individual dit ces among programmers exist, but 
that the variability is so large that experimental results 
ual differences than on experiman- 
@ebiy irduced differences" [Ref. 9: p. 317]. Hoat Might pe 
Mery difficult for one programmer may be easy for another 
mots nullirying the value of that predictor. Programmer 
performance must be based on a combination of oprogran 
related complexity measures, programmer f2ee Ss and 


Frogrammer tasks. 
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One of the newest approaches tc measuring complexity 
has beer presented by Halstead in which iines of code are 
broken dewn into operators and operands. Three advantaces 


@f this approach are: 


1. An Sees methodology EGaumCoIeorating 4 


2. A more nearly universal measure, Since the 
approach is consistent across the boundaries of 
orcgramming lengquadqes. 

Seber abiskiny tO Folate ssccms of the etfects. of 
peo be iim Stvyiea ao measured Went eseres. 
Merete 0+ Pages? 3 } 

The tules for this method seen tc combine lines of ccde 


O° 
Gecisicn nodes and operation codes, variables and punctua- 
2) 


phasis given to e¢ach area is questionable but 


J 
® 
| 
2 § 
(ib 
(D 
=| 


a 
mmemcast =hey are all inciuded. [Ref. 10: p. 374} 


Halstead Saenes S=[Ggth 25 2 <Si3"ct2Or oF Sun Of 
Beera Ot usaqée anc operand usage. Bence. Capeee | 2Sc ite sd 
MeimevOCcaDULaTY With Esascnable certainty according <=c 
Hals*e¢ad. Volume is a function of vocabular and lenath. 
Lines of code, length and volume are equally valid as rela- 


tive measures cf program size. PSogean) 52 Zz 
Mires cf code, length cr voiume is ai ia 
Haistead also presents an equation for measuring 


Gitficuity. Difficulty is defined as the measure of ease of 
<e 


reading and ¢ase of writing a program. Deke  CULZyY s2rects 
mie erfort needed =0 cod= an algoricha, =O imnspecc and 
review it and to evaiuate it later when changes need to be 
feae tO it. Various levels of difficulty are experienced 
due to the skill level of the programmer, voor preadaranm 
Seeuecture or the lack cr experience with alanguage and 


Pessibly the complexity of the algorithm. [Ref. 10: p. 381] 
Meieocead identities six code impurities that if eliminated 
reduce +he level 

follows: 


Srmcenpe=Xiltyeot the program. They are as 





1. Complementary Operations: unreduced expressions 

2. Ambiguous Operands: the same variable means 
q@2f£trerene cu2ngs 

3. Synonymous Cperands: giving the same value to more 
than one variabie name 

4. Common Subexpressions: subexpressions used more than 
cnc2 in a program. The subexpression should be given 
@ unique variable name 

cee Unda t=reas ced Shssigmhe nis: 


a 
a subexpression even though th 


once in the pregranm 

Oe Urfactored Expressions: easy to understand Dut at 
mec habia =O FOLLOW in codind. fRef. 10: PD. 
382-383] | 


Halstead's measures are attractive in that they are easy to 
automates. 


~*~ a =~ ~ ~— aS - «= -_ = ions ~ x ~ ~ 
peewee. Weaci =e Cf Cenplex:<7 thet hes echieved ecne 
D 


(bd 


SUrDS cruniversai acceptance is that pr 
mn 


D 

Wy 

Vf) 67) 
er 

i 

ib 

a 

yp 

| 


a 

MeCarce. Maeenie@ate Ss CY Clomavac COnNpLexity 

Meesls.Or POintS in the Procedure Division cf a p I 

Bemewed, «hese for each paGagraph and section are su 

and those for the entire pregram are summed. A paragra 

assumed +o be the size of a moduie and assigned a co: 

Maeuie Of One to Start. When a complex corditionali si 

ms encountered, each simple conditional expression is 

assigned a value of one, Research to correlate Haistead's 

and McCace's measures with programming erfort have shown the 

following (especiaily respecting Halstsad's work): 

1. Feasonable correlation exists between the measures 
and programming effort. 

2. A comparable correlation exists bétween the measures 
and the number of instructions in the programs. 

coe um berre or instrwetions seem to ke as good an indi- 


cater of software development effort required for 
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large programs (over 1000 DSI (delivered socurcse 

instructions)) as *he Haistaad and McCabe measures. 
Me measures, however, correlate better than DSI with tne 
amour.t of terminal time required to program small programs. 
fRef. 3: pe. 481] 

The weaknesses of the measures lie in their not 
accounting for such factors as personnel experience 
ware constraints, manageriai factors and zhe use 


e 
and modern programming practices. The user must siso oscome 


accustomed to using zhe measures and, as already statea, czhe 
Meeesires involve a Khcwledg¢ cit program characteristics *1at 
meee roe learned Until th= program is written. 
Peele. =o tenence 

Intsetzerence factors include the Ora Oe sae 
@2s*eurtberces Ena affect B2ogeciners* DEOQwe = asin. 
ese e TVD OL wmROr=Clirect work includss such activities 
Memeo DT eDaration, union meetings, and status Teter 
submissicns. Sect cin erences: Ors 252 a Seccnd scuzce of 
mye sOSS, Thirdly, interzieréence includes the mec 


© rege 
Seng a2 Creative <«ancughe pattern erter interr 
Vv n 


@ people are subject to environmental i 


their ability to evolve a new progran. Aeon  SOUsIee) 0: 
Beeerterence is the time spent coordinatzn with other 
prcoqrammers while developing a pfrogrzn. tee ee SOUS cS OF 
snterference is the number of miscellaneous interruptions 


Maas Cesult from passing social interactions, trips to the 
head, e=c. [Ref. 8: pp. 164-166 ] 


Interccmmunication is essential to any project. TO 
Minimize intercommunication, as few people as possible 


should be involved in a large project if completion time is 
importan* (as inevitably it is). Brooks suggests the use of 
programmer teams tO improve upon the completion time cf a 


Bao ject. The task is divided up into a@ number of ssagqments 
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and each tsam operates on its own as far as possible to 
complete a segment of the project. Esterling's research 
showed that programmer productivity can be increased in an 
interrupt free environment. Interference factors command a 
large perticn of the programmer's time and mus* be addressed 


in any estimation of cost and effort. 


€ngineering economics due to the many cost overruns on softrt- 
Meee Engines ting projects. Cest overruns have becone tne 
Meevand ifectcr #n ¢ftor=s to develoo software cost and 
meeeat e¢Stimating techniques. Mecadlacsang personnel costs 
have driven companies to new awareness of software develop- 
ment prejects. A severe shortage of software engineers 
presently exists along with greater Shortages in the number 
Of senior software engineers whose competence ani exvertise 
Memeecusazng a DpEOVECt Can Often Tresuit an an outstancing 
Meoauc. eS spposed tc a mediccre croduct. Pie 405) Mat tse 
Mee SOttWare engineers is good and “the cost of nhirtina 
Peoqgrteammers ard analysts cecntinues to grow in dominance in 
the overall cost picture. BStam@e es indicate thasethe cost 
per man-year of a software engineer will be 100,000 dollars 


by the mid 1980's (this includes salary, fringe benefits and 


EMppOLt costs). 


Software projects wili usually take at least two =o 
three years to complete. One" programmes will usually not 
surfice to compiete a project so a number cf salaried scit- 
ware engineers must be anewewoae ed). But as alreadv 
discussed, adding programmers to accelerate a software 


ie 
development project will only pe beneficial up to 2 certain 
de 


point beyond which diminishing returns will be realize 
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Initiel development cost may be expensive for a 
PEOject EUt experience Indicates that for every five dollars 
spent on initial development, between seven and twenty 
dollars will be spent on maintenance. With #his skyrock- 
€éting picture of costs throughout the lirecycle of a 
project, estimates for 2 software development project and 
the subsequent plans for and implementation of a software 
Gevelcpmen= project mnusz DE carefully nanaged. So ncecso 


much of costs Will involve personnel, software develonvment 


Mie SOmher is will ke increasingly Ils0ked to for the best 
ways to exploit the potential of software engineers. 


fe 
ee 2) 


ESeeenas ee adeca. ec “nh 
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wre Ne wcet, tne e£Ora! cose 
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G wath development =: 


tO workers. iam Pema Ateqte tS paid, the ovetrali cos 
Beeweasces;: if double time is paid, the overall cost remains 
@enstar.. Pee seecemcock = 4 80 heye a4 separaise impact cn 
Cverrtime work since «hey do not vary over time. fica ye eas 
Mme TeGe COStS are high, savings can be reaiized by hiring 
Me@eulceieeS and by-tne-nour psople. [{Reft. 8: pp. 1707 


Thus we see that tne primary driver of the cost of a 
software development project is the personnel involved. 
Personnel must be caréfuliy selected fF ee ine “Some 


ir sated 


Q 
ws 
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ct 
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ware development project. As will be 
emperlence of the proqrammer is of c 

After personnel are selectsad for 
management process implemented wil 


al 
their collective potential is exploited. 
2. Quality 


The quality desired in a given software product will 


ferectl Pieiietecommtic —COSt and effort devoted =o tha 
Meo 7ec =. Quality will generally vary according to che 
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Reese Of the project. Software developed for @ manned 

Mitre degntewad? cl necessszy be of far greater guality 
than that to support standard business applications. 

Remus defines quality as "...the number of program 

defects normalized by size over time" (Ref. 5: p. 268]. we 

m@mthisc tO D2 a USefui, worxing definition cf quaiity. 


ae 
Quality cr a software product can be improved by increased 


Pecenticon given to the EEOMeseid design process With 
emphasis cn modularization. N@aWteneZeation OF alVeding {ne 
DEO t=C~ i1n7z6 SMaldi sé€gnants thet ar2= more intsiligibie 
enables she programmer to mere easily understand the cobjec- 
tiv? of a *ask asSidqned. A better understood assignment 


Vv 
Mere tead to a better product. 
Programming EGnvaronmen: has a Si19hirican= impact on 


Pm@ality. The ability or she programmers to work in an envi- 
v 


( 


momen. cCOnducive =o and supportive of creatl 
s 


meet = Superior Software tvroduct. 


Bee Geese C= otalt2cy SOTEWarsaMLi] noi cc down as 
S@eemaeticaliy as <the cest of hardware [Ref. 11: pam Ol. 
Bely) Cicep, UNWaZrTLranted, unsupported software will appear cen 
zne market and be availapbl2= +*to the consumer. Inexpensive, 
Mess marketed, supported scftware is not a practical possi- 
m_mememvyercOr —~he future. Four types of software products wiil 
be available in the future: 

ieee teraty pred@ers requiring no supoort and known 
MomecenmeGenect 2nd =O LURScLOon predictably and 
Beliaply 

Zoe OWeL i. ¥ products that are sold to customers 
Wanda O Pay <he Support cost 

3. Custom-made products, developed for a specific 
user's needs 


Peet emOl ners. [ReE. tls p. 227] 


a) 





Pemces £eCa type | products wili be high and vary accordin 


to market demand. Tyeee eo wEECauecres will be priced cconsider- 
ably higher than type 1 products. Type 3 products will be 


the highest priced of all scftware. Type 4 products will be 
mederately priced for mass ccnsumption. Especially sopnis- 
ticated software will be sold along with associated hardware 


in what will be a turnkey systen. 
me weocnecdul ing 


Seneca nas 2NDeCErant in  SOLtware 


projects so as 70 avoid siow down ina The 
[een O- COOLGIAatLOn among interdependent s2qments of tne 
peo ect. Sere ng Siovc Wiese in time ali important 
project avents take place. Mie Se. =G's sheared. =1elidas 
milestones, reviews, key meetings, audits, documentaticn 


releases and product delivery datas. 


4 5 4 _— nt : —= Jas i ad ie Gj “+ - 
Sen OUewegees a. SC 2N2Cr tease 29> MArKeki ng’ ard sales 
h 


pur peses,. A peeewer@his: be aevyatladie at the =ime when *he 
Meas keting personnel Aave oremised it. ie SOee Om) foe eg 6 or 
any O©TdGanhization is customer satisfaction and hence profic. 
PEQ ject MaNaqement dirters Erom preduction nanace- 
Ment in the nature of tne task. Production management 
involves the performance of a oo Ow Project 
Management is mucn more difficu mn fetes ee (6 jOD “20. «be 
Begeormed and the resul+s cf tne effort are not clearlv 
Meeee=©Ccd a~ the outset and are unigue for th? nos* part. 
Lol sOWeng Cchatacteris<ics apply «+o all orojects in 
varying degrees: 
fee L2ne project itseli will last for weeks, Nene hoo = 


even years. During this tine, many changes may occur 
Mime deDEOveceeWalcn May affect cost, technology and 
resources. 

2e The project is usually complex involving many inter- 


BetoweaquaGecevotics that must be monitored. 


ap 





3. Projects are expected to be completed on time wit 


+ 
t 


any delays costing the developers into thousands of 
dollars per day of delay. Not only is money ics* but 
aiso much i111 will may be created from overdue 


SOneCc —S. 


a ®) 


[ETO T2Gt> —G2zter dre sSquential in mature with the 
start of one project dependent on the completion of 
gremmec. ) (kere 2s ps. 273) 

popes oe emer e ee peauc= OF DEC }]SCcts, Dienninea, 
Bemeercl ala cOOlctdinaticn of proj 


hac ceguires cics® atteanticn. Veer Teeceatay, MO Lorpral, 
generally applicabl2= method was available to manage the 
Beegress OL projects. Two methods are now available that 
have proven +o be very us2ful in project management: le jadeely 
(Program Evaluation and Review Tachnigque Snueee le (Csr tc i. 
Path Method). 

PACE Seep emces SH15- 5DetySsen PERT ana Cr pipet =: 
Mie VOLVES S=Stifteting activity durtatiecns. SAMMI © eatin Ss 


Oo 
“J 
rey) 


R 
Seager =O arrive at an expectsd co 
9 y ° 


Peopab: lity distribution of completion tines. Because cf 
fms, PORT 2S looked upon as 4 probabilis=ic tool. CPM is 2 
deterministic cool, He. ,eOonlyeone “eStimets is nade .2o0r 
SiiedtiOn Of an activity. The second difference between ine 
two methods is that CPM can give an estimate of ccests as 
weil aS compietion time for @ project. PERT is fundamen- 

Mets Sal teok tHak 


Meme c TOOl tO plan and control ztime; CP 
memeepe used +O pian and control both tin 
bao }€Ct. 

PERT and CPM attempt tO answer the followinc 


guestions: 
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ieee wet iyIe cs ate Critical? That is, #! 
pe be completed comeene tO Keep =£he projyec= on 


2 a Cn act mma 1eS are noncritical? 


3. How much flexibility does management have in 
execu Pidethne monc bitical activities? 
WY What is the earliast expected comovletion date for 


<heeprojece: 


5. What is. the best way to. handle delays that are 
detected durin execution o= the Dine teGu. 
(Ref. 12: pp. 274-275] 


(Pn oc ome Sette chance Cl COmpleting 4a. project by a 
destecdmda ze ? 

Poem | OGL VhOwMmEenG Sheutd 4a projec: be planned so. that 
Sc v- De ese bent Ie y oO: completion is attained? 
fRef. 12: pp. 274-275] 

GEN “e2swer]e ene Sol lcWeng eddizional questions; 

[Peec Seo ree, lea ==-COsSs= Way <0 .expedite the 

-_ . “ 
COND Lewmon C= a Dr cjyect : 

Peeeeiat 25 the Sheeresc possibile “tame for a oroject 
Bo De Completed? [ReEr. 12: pp. 274-275 } 

PERT and CPM orovide numerous advantages [cor the 
project manager. The rfeaquirements of the methods force 
2ne wnat nas to be 


Managers to pian ahead in detail to datern na 

done to meat project cbjectives on schedule. Definite deci- 
Sions must be made regarding execution times and completion 
mimes [CD activities in the project. The stools of CPMH and 


PERT provide for improved communication among departments in 


the organization and between the developer and clients. The 
Metewees allow for identifying critical activities in «he 


Meejecc and thus cicse a+tention can be given to these 


phases. Beeccmme = Cal 2CtiVvV2ty,es dre most likely =o be 
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potential problem areas, these dirficuities can be spotte: 
early and adequately planned for. 


Resources are more easily managed using PERT ani 


CPM. Once bottienecxs and problems are identified in the 
BeO ject, resources can be more easily moved around to 
Gerrect difficulties. Deviations from schedules are more 


easily identified and accommodated. , Since PERT and CPM 


Meovide an overall picture cf the project, the tcols can be 
nuseq casily to present the voroject +o lowar ievels of 
managemen. Pest and CPM ame casiiy adapted to conputers. 
Alternate ways of executing projecz=s can be evaluated using 
Peeeand CPM. PERT provides the probability of completing a 
project cn schedule while CPM allows management to evaluate 
meemeecs-S O- LUShIing activities. Ware jesse acd ag) SroalLeils 
can be avoided through close adherence to managenenz tools 


a 
mide. .Onelly con=ribuve «+0 2 project's succ2ss 435 the 
employees will reaiize personal gra 


on 
aca mét. Improved motivation will mean an improved product. 


Pe eeess ExXper ence 
Past experience plays 2 significant role in software 
deveiopment projects. Companies that have past experience 


ro 
Dd 


in large jobs will tend to overestimate a job and manage = 
job as a large job. Companies with experience in small jebs 
Will cend to underestimate a job and manage it as a smail 
job. This antire concept has been negiected in each cost 
and erfort estimating model reviewed by «hese researchers. 
fRef. 13: p. 43] 
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Research has found that experience ils important if 
the experience that a pregrammer haS is related to the 
eurcrent project. Merely programming for a number of years 
will not mean that someon? is a good programmer, only that 
he has been programming for a number of y#2ars. He may have 
been making the same mistakes and using the same procédures 
Gurinq those vears. So the developmental voattern of tne 
individual programmer and analyst must oe examined in order 

D 


Memascert eth the maturetv of the individual. 


miei. On up to™Z021. Liter 


a m 
will be addressed again in another segment of taAiS paper. 


ls have become increasingly a topic of 
2 
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M@ySsc L5G Aas Seen deserised as %*...7a¢ 
discipline of analyzing and understanding the requirements 
Bee Gua-=-Y¥ SOftware engineerin moors. and Of trans -dewng 
Smee UnderStanding into innovative toql design" [Ref. 11: pb. 
223). 

Beaouem. Gs  Geaqis with ~he nutuai edjustmen= of ‘man 
and machine. Wen shes done mos] of the adjusting as of this 
time énd machines now must adjust +o human needs. Gnas 


Memit2on naS C@eme about due #0 the increased costs of 


meeenGc and SlUpporsing programmers. Man initially exerted 


femeet.Or7sS tO explicit computer capadpilities; now, computers 
must evolve to exploit human potential. The sasier softwares 
development tools are to use and the more affecti 


= 
ive they are 
in assisting the programmer to produce his product the more 


efficient will be the entire development program. 
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divided 


ile 


The tcols used during the production process can be 


into a number of grcups. 


The 


design language should be generai enough to 


permit a description in genaral terms and specific 


enough to be unambiguous. Miewyezehameass:St. in 


finding obvious problems and automate some intercon- 


Nec@2On cross) references. Tools such as the Problen 


Se 


atemen= Language/Problem Statement Analyzer are 


CoD is ena een ce Seo lseac AsSGunNengte-~1ion and analysis 


= s ~ 7 


techhiques tnat aid in developing the requirements 


Gea speecantcCe: Ons £Ot a progra 


n 
*ion of documentation as the project proceeds. 


Bee CrsS werd On=uin]e document handling facilities 


ellow mechine use 


Its 


CE WE tang, ESOCadUuclhgG and Main-= 


Taijning specifications and user _— 


Geme ie aaaey cecliztzes Lilpreve testing end int<eqzra- 


bE SX ie fe Bees = 
BEG e Ot Geta =Or COdCS Srrors. 


Se.eCessene LUN CtIONS, BOVE ss She Lou. 


Seat Ss Ssegnettcan= date entities andc 


Security and access control for data base environ- 
ments 

Stam@oarcazetiones f data el=eme 
Identifies redundancies in the data base 
Automatic documentation w bm 
Improved transportability petween comp 
ronments 

Assists auditing [Ref. 14] 

Interactive cod? ‘facilitates program developmen: 
allowing each programmer to use a terminai in his 


work 
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h) Test simuletors allow simulation of complicated 
hardware configurations 

i) Test control and test case libraries facilitates 
testing procedures 

j) Service data bases provide soluticns to errors 
fcund that are not yet corrected for public usade. 
{ Ref. Ss pp. 273-274] 

Software Development Envirennent (SDE) is tha rane 


Mmensea £O describe tne *zec 


mMelatweon =o one another, or as sophisicated a 
Metrnodo logy  Uusitg tools or software Perec. 
thaz are highiy integrated and non-repetitious. frets 15:2 


pe. 20] SDE is a recently developed concept. 


Menor ce2= 7s the scftware developtent -4nvirtonnent skeuld 
be adévotable, aser-ceac2red,_ Sucdsstive,  aclinptul era 
Speer tive, not impcsing. Re VOCS WEL Gs] sivitcniens 
Smouid be portabie, methodology incerendent, cataiogued 
Mesa respect £0 ‘ ssumed ee = Gce Mere CaclOn 20d  fn=y 
Smoulc eve &@ Sspecitic purocse. Pee ty). le <nvsror- 
ment should support large-scale software production and 
Meee wc CORS@ Soca - 2N=ertece through “he |sncirce sorft- 
eee ets cycie. [ Ref. 15: p. 21] 

eee Snhevld provide tools that are integrated and user 

meeendly. User friendly chatacteristics should include such 

meengs aS human interfaces other than text, suck as nenu 


selection capability, graphics and possibly voice reéecogni- 
OT). Not much concern has been shown up to now as to the 
cost cf implementing such environments or the cest of 
Sustaining such 2nvironments [Ref. 15: p. 21]. 


Common potential benefits to be derived from the u 


("A 
iD 


@emoOE include improved software quality, reduced cost of 
software, improved programmer productivity, and more tanage- 
Ment visibility. The prevalent feeling is that the use of 


seorttware tools and the SDE is gcod but as of now 
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mentai data exists tc corroborate these feelings. 
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The cost of SDE has not been closely studied as thse 
environments have been developed to support large systems 
and these systems are usually used by large organizations 
that have substantial resources. Most cof the effort is 
directed toward supporting the development phase and not the 

aintenance phase. Companies feel that the development cost 

will be snortened and therefore support the SDE. Not much 

attention is paid to the maintenance nhase as maintenance is 
m 


e a = - e oR 
mee = en 6h SCUST CE CE trcome fer fhe co 


We believe that lixztie attention has been given to 
estimating maintenance costs for the same reason: maonte- 
Rance is seen as @ scurce of revenue S 
@ number of components. The software development t 


in some cases an implicit set of operating opr 
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An automated software develooment environnent 
requires sophisicated software support for complex directo- 
Ties of files, a sophisicated databas management system and 
@ standard interactive capability. ThesS capabiliities 


requires considéerabie hardware support. 


SDE has had a stated goal of reducing the ime to 
deveicp software. Studies done by Boehn indicate that ths 


development time ls not reduced but that the time spent in 
development is shifted from writing scurce code and debuc- 
ging to developing «he requirements and specificaxions. 
{Ref. 16] The major problem with the concent of a software 
development environment is getting companies to aliccate 


necessary funds to lts develcpment 2nd support. Hardwate, 





personnel and training must 


ware develcpment environment 


Operaticn in the company. 


9. Management Policies 


Management by Objectives (MBO) 


be provided to impl 


atid to 


me 


Newt a SOLZe= 


a 


maintain its smooth 


is quite compatible 


with using PERT and CPM and scheduling methods. "MBO retars 
meme formal, Of modereteiy formal, Set of procedures thar 
mMegen= With goal setting and continues through pericormance 
mevyoew" (Ref. 17: pe 14473. WEOpsy a Das Le=>etive Broccsss 
that invelvées communication among managers and staft nembders 
ax ali levels. Po cape esne dy tanks OF COMmMmUNicatior faciii-~ 
Seeare tne plannang and conerol of a project. MBO assumes 
that workers are motivated to perform their jobs and want <to 


do as good a job as pessibie. 
@earted Theory Y, is cppesed t 


ao (ieee: ‘OL: Silt 


duals who 


They generally are n 
Scientific people and are 
she fuliest potential of the 
Maneger will recognize 
those needs to 
insure a 


PEOauct, and 


programmers and programming teams and 


rol2= of a prodqran 


Mmeeer in the research. 


the needs of 
alicw the programmers 


cooperative 


manager will 


Tris view of human pehavior, 


PiSsOry Ak, a ed ee te bes 


ntcerest nie) other OL= 
Concerned aneut exploiting 
COMPS i. A sharp program 
his progrémmers, meet 

he - Drcgucs: thease pos 
Climat? exists anong 


G@eoups ne Crier Ca 1 


be more closely addressed 


MBO involves primarily the establishment of acais 
eaeeugn a joint effort of nanagement and subordinetes. 
Objective measures cf performarce are arrived act, 22 SS 
lines of source code generated. Performance reviews and 
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regular periodic reviews are made. A primary purpose cri MBO 
is to achieve efficient operation of an crganization through 
mien eriic lent Operat: on and coordination of itS parts. ise 
has great vaiue in performance planning and appraisai. 
Managers in the organizaticn are encouraged *o work with 


personnel above and telcw them in an effort to achieve the 


best croduct possible. When problems arise, the team works 
together to solve them rather than to seek scmeone to hang. 
Since prcogqrammers are creative people, predqressive manage- 
men< BOLL Clies ee ee MBO emphasizing +he goals ons 
Bepe-actUalization are encouraged. 


Sottwares development projects ars often large scales 

Mmaeggiects Lequiting the highest coordination. The gualities 

Mage the Federal Government see¢kS in itS prodram managers 

MMe re 2 «presented f0=> zheir overall apoliication te any 
a (o 


W O 
MevyesOMerL= acquisition 85 the driver behird a sottwatre 
déveicpment project. Me wekaraGreniest=cs os. th 

Manager who guides a software development oroje 
meebeti cn Will be criticai fer the success or the project. 
PagegonG @n acquisition program for a large scaieé, govern- 
Ment purchase is a demanding task and requires an individual 
OZ unique skiils and personal character traits. “The accon- 
Seeshment of meees Ob Vective requires the successful 
firegtation of people, financial and material resources...in 
one wcerc--Management" [Ref. 182 p. 8 }. "A program manager 
1s expected to have an in-depth technical understanding of 


Meee rceS, =O plan, Organize, and control with the preci- 


Sion cof a military campaigner, +0 integrate ideas ard write 
exe a journalist,’ and to build and motivate a team of 
managers he may have never met berore or work with again" 
meet. 19: pe 6]. Mew eeaperstbhiteay fer the success or 


(2) 
es 





faiiure of the acquisition program lies in the hands of the 
program manager. The jcb must be done eff Soe Within 
<ne budget and on time. The success of the program will be 


a direct reflection on how weil the team has been motivated 


to achieve its goal. 


(D 


Even iz we know the proper way to build and motivat 
aproject team, more impcrtantly we must find a progran 
Menager who can successfully implement «his knowledge. #4cs* 
importentiy, a orogram manager should be an individuai with 

ets 


Pecos. -ive attitude end keen insi 


Successful projects emerges from pecvle who believe that the 
job can be done regardiess cf the onpstacles. If the program 
maneger is a positive tainker fee ween SOS Tes TnL S azcacuda= 


faeoe ss «6h SCAM. 


An achieving program manager wili demand outstanding 


Besults, Qutstanding effort is admirable bux if the product 
Meomnor Gelivered as advertised, <zhe effort is =enpty. 1s 
Meecuec= cn has been taking an inordinate amount of time on 
meee@et>- Of certain individuals, personnel reassignments 
Snould re considered. A pregram manacer skculd be one who 
remains above interteam squabbles and criticism and be the 
meeeevedudal who pucs sucn destructive forces =o tra2st. H= 
snould ke an individual who is bound by his werk, keeps his 
promises and thereby generates a retling of confidence 2nd 


certainty within team members. [{Ref. 20] 
An effective manager "...must have skiil in commun:i- 
cations, which spans such areas as the ability to 2xpress 


dees clearly, the ability to iead discussicns and arbitrate 


differences, tne ability tc ask the kind of questions thax 
Stimulate and encourag? creative heme nge and prerien 
solving. He must also master the skill of listening---so 


that he understands what is said and what lies behind tne 
Mesas" [ Ref. 21: p. 15}. 


Ps 





ecent study indicated that emplo 
rs with supervisors. as the a 
ortant relationships in the worki 
ast able to estabiish. In another study conducted at 
oycia University, | essential. Pawoleees Ors a  gcod 
manager were Compiled. It was found most important that 


yees view communica- 
NOS seSceceanyang and 
ng environment, _but 
ie 
ws 


rey) 
ct 


managers listen well, Since attentive Listening is the 
Dest way tO Stay in touch with _ everything that is 
happening, such managers are well informed. Good 
listening, in addition to keeping Managers well 
fee ote promotes good human relations. fRef. 22: pp. 


qram manager must feel secure within himself. 
Heme Oe tete on swe hh eae xnowledge that he. will 


fo wee ecOlara Stes fOr HEHE SUCCSSss OD Tazilure of 


Meemaediest-1Cn GEOg=am and will oe dealt with accordingly. 
Above ali eise, we reel that a2 program manager must have a 
sealent for human understanding. H2 must have insight into 
benavicral patterns that indicate personal or professional 
Scoubls wichin the staft member. Through personal attention 
@emanhe Leeds of the individual, Domwe | ge2ecage a lovaltcy 
Meco Wan/lemOcuivat2 =he best actions from ~he indivivual thus 


Peace rs Seesen for future echieveneaents and tnrrusting 
MeemwGUcten= project to a successful compietion. 

Above all elise, tne program manager is the kay to a 
Bea ject*s success. Sound estimates of cest and effort wiil 
be tor naught if a ccmpetent program manager is not at the 


heim. 





Ili. SOPTWARE LIFECYCLE: MAJOR PHASES AND ACTIVITIES 


This chapter describes the major phases and activities 
a software development project. Wo these nvewectyoe OF 
EO jSct, whether it be developing a software system or 


building a little red wagon, a person needs to know exactly 


Wwrat it is he is setting out to de befers he can even begin 
Boeestimete what ne needs in terms of time, money end 
Peecr. tO complete the oro ject. Pie ugeout —ne itera ure 
EmeSO™LWare 2ndinsering economics, reference is made to thse 
fecrecycle pnases or software development Deo gec os. 

C-aa = 


Mies olty, a project is broker down into pasts s 
a 


* appear to be an insurmountable task may be 


re of less complex components. An under- 
Mpeg C- the wDrases 2rd activities invelved in the 
Merc s.Or OL SCiitWare 35 the tirs= sisp toward answering 
meee Ques or "Nhere dces the monev cgo?", 
A. MAJOEB PHASES 
1. System Requirements /Fea sibilit 
Wwe will devote considerable attention to «his phase 
ee che software lifecycle. BeGewOnten We -Ghasge Ori To 
Battie when no war exists. The corporates manager must first 


determine that areal need exists in his company and that 
W 


*he need can best be satisfied with improved software or 
meraliy computerizing an area of his operations. The 
Bc ivea problems, however, may b2 found to be sclivable 

3thin his existing framaworck. 
During the system requirements/feasibili+ chase, 


scftware concepts must be delineated and avaluated and a 


referred alternative chosen by management. 
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See the need for a new information system is perceived 
f€asi Bpility stmwdy determines whetner or not desire 
Be aece zves of a proposed information system can be 


eved within existing Constraints. Poovey ee Stl 
fies Bene weOse Of PEOpoOsed Chan (monetary and 
Organizational) and. estimates the saeeics Or tne new 
System. On (thes 1) 8Or Nason, the manager decides 


whether +o implement the new syst SMeor Giscont ome the 
Seeudy. Wi Ref. 233 Pp. 3] 


A feasibility study is undertaken when the need for 
2 


ttéer iniormation system 1S perceived by an organ- 


Beza ci Ch. A rzmeasloa pee y See y .5 2 COS feel MiiGew. CaeeeG Gia 
» jong -_— A Ke = = ct a tn om = ° ~ ANMiA ~ a, as AS am 
Meroe beginning "he coOnNDany snacnid evaluate whether 


Woon ad S©LeWarec G2vslooment Dro }Jec = is contemplated, 
Hha —eerte ayic=4 engnf\"ywaro an Ica we “="“asaRr - Aatare 
we 46 be NMaxrkK en — So oy =©@ 22 2S SseiOulLlcd on ]@xeRninzn 2c © Aerer 
Mine whketner the needed wnesl has alreacy been invented. [hn 
BeoesSing tas TSequzrtements Sf a particular sctuwezre cevelop- 
Men= Lrojec:, ~The @eXisting hardware must be reviewed as to 
Meee s §= Cal) DEFSOrM UD tS Zhe expectations and Gaemarnds of 


feemeoedame Zing £C=> the feasibility s«=udy. 
woeemescaren £O> a So lutmvon. 
Demeneastoality analysis. 


SeerlonGe Or ag solutacens [Refs 23: pe 233) 


Phase one, organizing for a feasibility study, is 
dpa 


undertaken when one or all cf the following become a 


mene mGesm iW Orde iizaticnal goais, olans and infor- 
Mation requirements. 


be, 
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Phase One: Organizing for feasibility study 
1 






System 
oroblem 


| fecognition | 
3 


Formulation | 
ict need for 
system cnange 







Management 
|aoocints 
team fer study 






cee SE ee I es SE ey So eee compe, SIMS oe cts QED oa, yr 





Management 
states objectives, | 








policies, and 
constraints 
Pnmnase One 
| ad 
| Phase Two 


To Phase Two 


incite 2ae pp. 234 ] 


a acapella aie, SED oe Oa ee SD a EE a ee ee ee SD es oc “®  eee eee, ee o hee, SE Le 


[ enn mamma ES ene: ey a at 


—_—n at Li ee ee aE I ey 


Figure 3.1 Phase One: Organizing for feasibility study. 


Zome nan ges in Organizational Scruceurc Secs y 
appointment ci rew *op nanagement). 

3. Changes in the 2nvironment fers h legislation 

Vee ned data £0 


requiring the company <tc supp 
government agencies). 


4. Changes in +échnology «hat may make new systems 
Ecasible, [{ Ref. 23: p. 238] 
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If the need for change has been clearly 1 
+hen management must undertake to clearly define the prob- 
lems and search out possible solutions. A feasibility study 
team is recommended for this task. The team usually 
Bensists of twe to eight members with the following 


Mga 1) fi cetions: 


1. Members snould reflect a knowledge cf the systen 
techniques. The nature of the orobléem wili determine 
Mee re= = hts Keewreag= be in She sa>ea cf ceeraticnrs 
Bee etc] oe ore es, CONPULSS SCL2ence, irrorma*ior 

e 


Nee Of Bileeaness Functions. 

Peeeevencers SPOUlGmneve che abilicy to relats to people 
e their work will lead them to changes w 

iduais in the company. Change and possib 

Ss ays ccencern employees and these 

*2dqa by the group members. 


af | NZ cd a —_— — ~ =~ 7 - Wa 
ged mave a2 therough understanding Of 2S 


a4, “4empers shoul 

oom Come wOVerall OLemUure of the orgqana 
5. Members shou av a 

GHel =. 


6. Members should nave experience in the project uncer 


@ensideczatsaon. [ Ref. 23: p. 235) 


Personnel may have to be hired +o meet some needed 
fla ds faca*ions. 


After the team has been identified, management will 


me =] ~he Cbhjectives orf the study and the related policies 


ea Constraints. The team will need =o know such things as 
Berg: ssible errer rate, how many decimal points enswers 


should be carried tc, response time requirements, the number 
Of users anticipated on +th2 system, lccation cf the users, 
om Goais ar2 set by management and the feasibility study 


is te determine whether the qcealis can be met within 
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Phase Two: Search for solutions 
From Phase One 





Phase One 
~ Phase Two 
6 Economic 
Analyze information 
existing 
system 3 


nee ee eeaet 
Organizational 
information 





Financial 
information 





Analyze 
relevant 
Gata 








Technical 
information 





ie ey ce ci ee ee ie SE 2 whee eee Sl Cee, Cee 


Feasibdie 
9 





Find 
methods of 9 


solution 
Shown in Figure 11.3 | Phase Two 


Phase Three 





To Phase Three 


[Ref. 23: p. 237] 


a ee CE a A ee. ie ein OE ng ek Re SM ye PS a 8 eee iD tied SE te, <Oe te Oe e Leee ee Oe coe Cee Cee Oe eet OO ee ee 


p——--—-=-----——- 


| 





Figure 3.2 Phase Two: Search for solutions. 


Beennolod:cal corstraintS and resource constraints of the 
company. T£ goals cannot be net as originally defined, 
€ither the goals are redefined cr the project is scrubbed. 
Fhaseée two, the search for solutions, may take two 
forms. For a situaticn where major overhuals are to be done 


on a system, a fresh approach to the problem disregarding 
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ee en 


[ Ref. 


Figure 3.3 


Phase Three: Feasibility analysis 


From Phase Two 





20 
Management 
14 
Feasibility 
21 analysis 
Specialists 
22 
Any 
No feasible Yes 
solution 
? 23 


Recommend 
feasidie 
metnods of 
solution 


management 





Preparation 
of analysis, 


schedules and 
budgets 


Documentation 
of proposed 
system 


To Phase Four 


23: p. 239] 





ES a SS ee See 


Phase Fhree: 
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Phase Two 





Phase Three 
15 


Economic 


constraints 





16 


Financial 
constraints 


Organizational 


constraints 





18 


Technical 
constraints 


19 


| Other 


Phase Three 
Phase Four 


Feasibility analysis. 


| 


A a ey AS, A el I cy a SE a, i cc SO ee, mg ee ee Ce Se ee ee i cee eis Se er OR et re i eee. oe eee ee eee eee ee eee 
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the existing system is recommended. When changes to the 
subsystems within the existing structures are to be under- 
fmeeene Gnen a thorough evaluation of all the information on 
the environment is recommended so that current oerformance 
of the system can be evaluated and changes recommended. 
Pret. 23: pp. 237-238 } 


The solutions uncovered in phase ¢ 
f 


phase three, feasibility analysis, r ae 
RPA onemr OU 4, 2.246 16he. ard Bechnicsa! Viabibicy consic- 
Seang amposed constraints. Meee Conon C¢ Feasibility co 
implementing a new system is usualiy accomolished odv 
Mmrcltlsend a cost~benerit nr ate of the proposed under- 
mex ind. The cost~penefizt analysis wili datermine whether 
#h2 benerits E<«the new system will oe greater than <n 
Beers required to implement the new systen. What must be 
Bee]2h into account are the costs enconvassing the softwara 


Meg 2stmenz=sS that nust be made men & naw Lnrormation systen 
Meee TEeVisSed inrotmMation system is contemplated. "The major 
reason Management Initormaticn Systems (MTS) have had so many 
Tailures and problems is the way systems designers view 
organizations, their members, and se temmeinGe==On Of can oMES 
Beeean chem” f~Ref. 24: p. 17}. although management inforna- 


tion systems are cited, the authors include any computer 


based information systems effort. Faulty views of the 
Megadvageticn result ina taulty design cf the information 
System and hence a less than optimal operating system. The 


4 


Socio-Technical System (STS) design approach offers excel-~ 
lent advice on implementing an information system by czaking 
a realistic view of the crganization. The feasibility study 
feemip WOuld dO well to reccmmend cr incorporate ideas from 
tais approach. BO ciwmede wc comme Cal seand sectal aspects of 4 


hew system must be considered in the design of the sys 
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STS is a. fairly recent. development in the west 
Smear = 2-2 Oneal Systems watch ars both morte satisityin 
their members and more effective in meeting 
requirements. This approach is _used for redesig 
existing work systems 2S well as for new site desi 
PRef. 24: p. 17] 
— . e ee 
| Phase Four: Choice of solution 
From Phase Three Phase Three 
26 Phase Four 
| Report | 
to | 
management 


Management 
review 





No 






solution 


é 30 


Authorization 
of Solution 
dudget and 
priority 








Select 
project 
personnel 
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End of 
feasibillty 
study 


Worth 


recycling 
? 


Yes No 


Go to box 5(See Figure 3.1) 


[Ref. 23: p. 248] 
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Figure 3.4 Phase Peur: Choice of solution. 
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PmecCnecemrolrencholce Of a solution, the feasibility 
team recommends various alternatives to management with a 
mankang cf their desirability. If no desirable solutions 
exist, Management mav want to change their constraints in 


erder to find a feasible solution. Although managenent will 


a" 
6 
\ 
ct 


have been involved in the feasibility study 
= 


qi 
D 
4 
fv 
] 


rogresses it must now make a firal review cr «he ali 
g 


mms and Settle on a choice. 


aspec able SOlUcLOn weO©® a proolen. hoe 2s 
phase, we look at the computer and th2 people who need to 
use 1%. For example, a company may considsr a number of 
ways cr paying its employees: Gas, COMPUtEZ I Zea payzoll 
Smecksc, manually produced payroll checks or direct deposit 
Memeo eeccounts f Ret. 252 p. 199] Other additional regquire- 
Memes MUS. be consic<ered before = selection of software or 
feo == _Opment cf software can begin: Pet@ecs. 26 Zine, 


Mestre) =7 GG DEOBaADILity, chance of iraud or thertt. 


When deSigring a system, documertat2=on shoulda - be 


. ® 


io. LPS. Document atio ho ioes=anewm sn bOon ths 


and in the 





See Spec fed. It shculd also be required tha= the various 
isvsis of documentation be consisten: (2-9., sub-programs 
Swe GCaticaton S 


a De" Wicwemz0re Ps. 811!) The =ol1 
mentation can be found in varying degre 


Ss 
software development projects in the phases indi 


Functional Requirements Document Propiem Definition 
Data Requirements Document Problem Definiticn 
Systém and Sub-System Svecs System Design 
Pregtam Specification System Besign 
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Data Base Specification System Desian 


Test Plan System Design 

User Manual Programming 
Operations Manual Programming 

Program Maintenance Manual Programming 

Test Analysis Report Test. [Ref. 27} 

During the course of a software development project, 

O@=2i communication and written documentation must be 
Semeeces =O-> tne best results sof a project. “A requirements 
S@eevyst#s Car aid in understanding both the problem and «tne 
MmemteortS among conziicting constraints, thereby ccntri- 
meen g =C the best solution” [Ref. 25: p. 199]. Abscluts 
necessities must be distinguished from belis and whisties. 


be. | 


Meme ard space linitations, facilizcies plans for the future, 
and individual facilities requirements must be addressed. 


The menev required for and the money availabis <*o implemen 


- > = <= —~ w= os s _ ~~ or } =~ > Les} a 

mee SYS ten NUSt Fe consi deread. The management ct ase 
— = -~ ~ ”~ == = ~ aon Fated - 

Meoq]ct mus— also ce considered. AS Al 


femme ates ocpular methcacS of NCNItOring procress. pe Ole (or 
all these questions have been answered, specifications of 3 
mempices SOlUZ=Z2On to the problem may becan" [Ref. 25: jp. 
199 }. To summarize, what is needed is "a complete, veaii- 
meee Sscec fication of the required functions, interfaces, 
Pmeeepe= =~ Comence for the software product" fFrRef. 33: p. 37]j. 

- Preliminary Design/Produc= Design 


rt 


) 
( 


When we look to determining the specifications o 
h 


the sorttware we are actually asking what do we want she 
software +o do? WE want to determine , for example, thse 
BOaeMat OF the input and ouput. What information would be 
desired for the production of a check and how should this 


information appear on the check. Algorithms must be consid- 
ered for deductions from the basic check such as 1lifa 


insurance and health insurance plans. 
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4. Detailed Design 
Much has been written about the design phase of a 


software development project. 


Momr=t-ctacte, A complex system is one in Which thers are 
SO many System States that it is difficult *o understand 
ROW to organize the program icgic so that ali states 
wiil be) Handled correctly. Tae obvious echni -Gue to 
appiy when confronting Cneus type OO: situation. a5 "Givide 
and rue. ' Pax Se eo ee 2 Pp EOduaMmz ig. and is 
[mone n as modularization. feoctlacezacnOr GOnSists -of 
fe inoe 2 BeocScmme.0-O StbprSGgsams (noduiss) which can 
Mee waoch have cohnections with 

De 


be compiled separately D 
Q“her modules. 28 


Myet 22S now considered 9 be the most effective way of 


Mame COMEG 2 SO22¥earES PEXV=eCT wes set forth in a classic 
Meeict= | by S-evens, Constantine and Meyers in 1974 and 
subsequently rerined and develoved by Parnas [Ref. 29], 
meet. 30), ([Rer. 31]. 

Boos oNole ee ene Seance ot Oy ROdUulesrizetzon is used. 


0 
Meee so2 25 then given <9 one progzanm 
proaqrammers perhaps organized int program 
meemmenced Dy BEOooKS (Ret. 7: pp. 29~37)]. When the work is 
modularized, it pecomes ¢casier ror the proarammers to undar- 
stand. Communicaticn ‘tines can be established between 
programming teams so that questions can be answered. Eac 


meduite is developed as an entity in itself and how it 


f-- 


i 
tS 3¢D cécomes the secret ct the module. The module w 
u 


meee "Certa*n =nputs and wiil deliver certain outp 


rl 


=e 
Mae inteznal workings of that dGuie will not be revealed to 
ne 


mo 
Signers of other modules. 1) module will =hen not be 


er) a 
Tt 


mpered with. 


The connections between modules ars the assumpticns 
which the modules mak2 about each other [{Ref. 32]. 
Modules have connections in controi via their entry and 
Peas pcints CoMmeece ons 10 data, =2|xpl™citiy via their 
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oe uments and eae and Se Cong! eps ont 93 data 
ferenced by more th one medule; and conre ns in 
inte Services which the nodules provide for one “another 


[Ref 28: p. 66]. 


The beauty of this concept is that development time 
is shortened and modifications can be mor2 easily made to 
@oe clack bex, he mcdule, when changes are required down 


+hko lines 


he 6Cadtvendc Doebhig 
ie ween meocemey | ASjuG = eaesS=]=, “SOltWwars LS actu- 
meeiy CiOGUICSd that MEStTS =~he Specifications and is certiilied 


to meet the user's reguire: 
224d wher it meets the sp 
meeeetc be validated when it proves tc do what the user 


fees tC LO dO. 


When converting data to code, ¢rrors are oftentines 
madé that ara not easily detected. HUONG Char acce= Used= 
Memeo Caught WluenhOUt Much j=fouble Dut correct characters 
eee improperly wiil pass uncetectad. 

Wee CzeCdibijity of data is often directly related to tne 
Se cinlof coding. Coding at the dita source m2y lead +o 
mmeiverteat crrors due t5 a misunderstancing ef the 
@eaqing Structure or oe ate i aoe yu Valea ard 
relevart codes. Trained coders, selected and supervised 
With care and motivated as te “the Ee Se Spe mon tog 
file>, Weak= fewer errors. f[Ref. 23: p. 163 


6. Denugqging and Testing 


Ermce COMpPUTeErS a2ES2 not fFOrgivilng in nature and 


react to any @2rrors, testing and debugging is extremely 
important. AZter each module has been coded, testing and 


debugging should be done; after each module has been tested 


separateiy, all the modules must be tested together as 2 
system. System tests including acceptance testing are of 


Seurs= very impcrtant. 
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wD 
a | 
4 
O 
rf 
in 


We can classify programming weccsaang io 
three types: 

ie. Syntax 

B Code Logic 

ee Peoblem Logic 

Symeaxk GESOrS wnclude such vrobiems a4 m 
Bez=entheses, incorrectly speliecd {and thus unrecognizabls) 
Cc 


Variabie names, wrong data codes and misccunted chara 


Some such bugs are cbvicus-a missvelled word or miza- 
eee cl cane oC OMMame Our DUS repert, fOr 2xample. | Other 
ame some oat r cule tO diSC2En, Such aS transterring 
Sremu sO 2sncecrreG~ly artsr an if Sstatemen= and dyoassing 
some intended saNstructions. Soles Co ners are 
-~nSidicus-Zor exaapie, . Seecceey SD Sele les 2G 01S Veri= 
able name for another in an ee ee Teese soules ma Y 
Seem undecipheranply randon. [kef. 33: ov. 311] 


[eenec mecaxX LawS OG the vayroil deducticns b 
u > 


Mmmer may render the output of the proqran useless 
ae. =} ser. 
pone yee cloud EOOk a Majer shaze of the 
Peeort Gevcred 20 4 Project, often as much as 504. With 
increased emphasis being put on the front-end deveiopment of 
4 proqram, this phase is ccnsuming less cf the resources of 
ites Prejzect and is generally consuming about 34% cf the 
effort. 
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Ope tats er 





This phase 
waré in production 
number cf areas are 

1. Operating pe 
course be av 
PeaOrs chat 
Wedet Hea 2On 
Wee ee =a. 5 
Changes 
change. [Re 


ie ACTIVITY DEFINI 


litecy 


each p 


development 


Prel: 


—_[T_ — =a =e 


aay 


Interface Det 
Deta 


Cede 


and 


Development 


JI HW WW £F& W FH — 


Validation 
4 


24, 


~w 12 


mus‘ 


and test 


Requirements Analysis: 


iled . 


Debuca: 


end 


ting the developed soft- 


A 


MD 


concerns implemer g 


and keéping that software functional. 


bon, | 


to be considered: 
rsonnel and comput 
ailable 

arise from usage 


oy 


¢ mus*® pe made 
ements change 
made 


P. 32] 
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cs 
Bee: 18 
eeeLon : 
16 % 
20% 
mag: 
Rese mG 


= 3a 


21%: 


and 


Testi 


Ovcaa=senal Demons ==ation: 


Summing the 


Four phases prior 


to code and 


debug shows 


lana ~ 


we allocate 


G6 % 


Of - Our 


ZPOccwmecliar there, 


20% 


goes to 


eo01ing, 


mae LOLiow cocing. 


anc 


the 


remaining 34% goes 
PGBs eis = 
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mle, 


p. 6350] 


the two maior 


phases 





In crder to enhance the reader's understanding ci just 


how the Gollars are being spent, a description of the activ- 


me1es 


involved is presented. A breakdown of the tasks 


performed within each activity during each phas¢ is 


presented in Table I. The completion of each major phase of 


mae SOftware iife cycie reagquires that various functions or 


activ 


twtnese 
12 


ities be performed during each phase. We SuUMmarizs 


Sct. Vities as 2ollows: 


= —-_— = ~ a -_- maa “~~ ~~ oe i ss ~ ee = ~ ™ — -_ - Es ee 
-— . 7 — =aileg ~ £ : Py ~ — wae os = 
Bevmeow Nard Mupde-c Of Sortwere functional, DeTTor 


fierce. "“RepmeEstce, An agaverit: 
S 


PsOcUC. Diesaam: De 


fecunscnt a: lon, PORK ete Cae = Levelt. srogramnine 
Management. 

Test Plannning: Specification, review, and undate cof 
eroduct test and acceptance test plans; acquisition 
of associated tes: drivers, test tocls and test data. 
Weme>iCatzon and Vaiztdeticn: Performances of indeéepen- 


C 
dent requirements validation, iesign verification and 
Vaiidation, product test, and acceptance test; acqui- 


Sition of requirements and design verification and 


Val idat,on tools. 
Peewee. Onreace Funct ions: Preject level management 
mume taONn S 3 includes project levei planning and 


Cenerole  COMtracce ana SuUbcOntract Management , ana 
GusTomer =nter face. 
Cenfiguration Management and Qualit Assurance: 


Cont igura con Management aeiudes DlOc iG 


49 





Project Tasks by Activity and Phase 


Activity 


Requirements 
analysis 


Product design 


Programming 


“NVans and 
Ieee feMments 


Analyze existing 
system, de- 
termine user 
needs, inte- 
grate, docu- 
ment, and 
iterate re- 
quirements 


Develop basic 


TABLE [I 





ee 


Product 
Design 


Update require- 
ments 


Develop proa- 


architecture; uct Cesign: 
modeis, pro- modeis, pro- 
totypes, risk totypes, risk 
analysis analysis 


Top-ievel per- 


Personnel plan- 


Programrurtig 


Update require- 
ments 


Update cesign 


Detailed design, 





nt 


ntegralion 
and Test 





Update require- 
ments 


Update design 


integrate soft- 


Ee OE cre SD cee OR RD A erty EE -ct ED eee, CE emis APE eens <nmaiials 2 LS A, TS A STE creat OE alias OO: cement ONE En My ED OED es, — 
— SE A AOS TOTS A TY I i A nD ee OS cca ate ener aE 
A Ee egy Peas 


sonnel and ning, acquire code and unit ware, update 
tools plan- tools, ulllities test, compo- components 
ning nent docu- 
mentation, 
integration 
planning 
Test planning Acceptance Oraft test plans, Detaiied test Detaiied test 
test requira- acquire test olans, acquire olans, install 
ments, top- tools test tools (ast tools 
‘evel test 
plans 
Verification and Validate re- V & V product V & V top por- Pertorm product 
validation Quirements, design, ac- tions of code, test, accep- 
| acquire re- Quire design V & V design tance test, 
{ quirements, V & V tools changes ¥Y & V design 
{ design V & V changes 
{ tools 
| Project office Project level Project levei Project level Project level 
| lunctions management, management, management, management, 
{ project MIS status momni- status mon status moni- 
| planning, toring, con- tonng, con- tonng, con- 
{ contracts, li- tracts, liaison, tracts, liaison, tracts, liaison, 
{ aison, etc. etc. etc. atc. 
| CM/OQA CM/QA plans, CM/QA of re- CM/QOA of re- CM/OA of re- 
| procedures, Quirements, quirements, quirements, 
acceptance design; proj- design; code, design; code, 
| pian, identify ect standards, operate |i- operate li- 
| CM/QA tools acquire orary brary; monitor 
CM/QA tools acceptance 
| plan 
| Manuais Cutline portions Draft users’, op- Full draft users’ Final users’, op- 
of users’ erators’ man- and opera- erators’, and 
| manual! uals, Outline tors’ manuais maintenance 
{ maintenance manuals 
f manual 
| {Ref. 3: p. 507 
a 


Sear a = SS ee Ss eee — A a aE a i 


i ieee AES ae 
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Gon eee ea taen, change control, EYaeus ACCOUNT ing, 

O@peretI1On Of Program SUppoOtt iibrary, development an 
monitoring of end item acceptance plan 
assurance includ¢s development and monitoring of 
project standards, and technical audits 
products and processes. 

ee iahuals: Development and update of users! manuals, 
Grere co: s* manuals, and Maintenance manuals. 
{Ref. 3: pp. 46-50] 


ee SUMMARY 


4 
i 
ib 
MD 
fs 
" 
jw 
i 
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= 
to 
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ae | 
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ie) 
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( 
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oe) 
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Pemrewd>= =<agineerindg economics if ne is =o not only under- 
epee ca SO CO@set. buts tO @1S Crdanizaction's d¢ée¥elspnent 
ee OL ts The fFoumdation of xnowie@ae that is laid thera 
Biem@iGernsng she SortWare ii fecvcis (2nd 2S is trues for ail 

wy tern OS Oise eon aaa 
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IV. EPFORT, TEME AND COST ESZINATION 


Pereirn we look specifically at the factors affeering 
mEortt, “ime and cost esti mations. We feel csthat focusing 


Geeaectention on this particulat area of software engi- 


organi Ei EOee mw 21] ano Cos” 
meweemate=s Will d@reczly affect the stabiiity and soivency of 
a comoany. Inaccurate estimates acco h 


e 
will preve to be underestimates and 
company of added resources that may cr may not 0 
jentiy available. A Oro] eceme may be scuttled du: 


maeor lity to provide additional support. 


Poe LLM AWD EFFORT ESTIMATING 


1. Experience and Judgement 


—_ ab =o eee 


tra 


? 


Every estimate is inrtluenced to some extent by «he 
€ 


experience and judgement of its auth Some ite! 


Suecing the estinate are s well understocd 


O 


ems to be replaced by the mere mechanical ap 
0 


rule, while others depend heavily upon the experience of the 
e=-aMatcr. {Ref. 36: pe 48} The person responsible for 


ensuring the validity of an estimate should ren 
aware of the skills and qualifications of the individual who 
lose 


prepared the estimate to give him/her a basis 


rs 


Been g .ctS accuracy. 


Productivity 


2. Programme 


Ww 


Frogrammér productivity plays a major in part in 
Sememetlicrs of the amount cf time and erfore that will be 


expended on a software development projecz. Paiecwoeragaaens 
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Shatz tolliow focus on some of the more Lmportant aspects of 
Beocuctivity. As productivity increases, software d 
ment costs decrease. fn addition to worker quality and 
fPecivaticn, productivity depends on the use of adv 
technology and ‘the proper use and training of workers to 
effectively interface with the new technology. S1Ve rs Sas 
investment in training and jcb modification should 1l¢ad to 
Mevencs in tre Liong-run due +0 increases PeOcuecuivoety. 
meet. 37 7 
oj 


iD 


ertain ner-numen elements =hatz can nave 2 
a 


Ten The development envircnment 


Mmemema KEY factor in this regard. One must ensure <+ha- 
adequat]© hardware and software support 1s availanle to thea 
proqrammers. Ca cornOot ne UNGONNCENE OS “STO}JSCeS tO  pEecons 
bettlenecked because *hroughput capacity, disk space, CPU 
capacity, or tne like nave been exceeded. The demand for 
*h2se computing resources during design, development, inte- 
gration 250 Sessc Several 7 GeCarcs “san Guring 
Seesatliors. The déiays causec Dy such bottlenecks resul* in 


Beegremmers. [ Ret. 38] 

Mm esielld aiso De noted thet POOr programmer produc- 
tivity is as much the resuit of bad management decisions and 
Peemning 4S it is the result of inadequate tools, or lack of 
talent. PEOQdUCtavity §15 arrectrpd by arn organization's 
sttucture, goals, product tyne and experience in developing 
software. Ges- Snmewld be taken to ensure thet an orgariza- 
tion's software CGevelooment process does not become 2 
hindrance tc productivity through imposed inflexible mnanage- 
iemoee procedures. [Ref. 39] 

According to Jack Stone ther¢ are certain changes 
that cou.d be made to the pregrammer's physical environment 
Semencrease his/her productivity. One of his suggesticns is 


tO give each programmer a privata office to ensure quiet 
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Surroundings rather than grouping th® programmers together 
meeke cattle in a box car, Another of his suggestions is 
<0 ensure that the programmer has available to him/her state 
of the art computer services (a CRT terminal with on-line 
interactive operating system controls, editors, compilecs, 
maa debug facilities). fRef. 40] As previcusiy discuss:d, 
imprcved programmer productivity is among the potential 


benefits that may be derived from the use of SDE. 
Rate 


> 
= — =< RS 


OGS— 92 Cduct on 


jw 
}-4 
OQ 


B WOrkKing Standazd of the typic 
ae = cer programmer man-month is 1 object instruccion/ man- 
Mem Wo2ch 2S equivalent to 156 instructions/man-month, or 
fogs instructions/man-year for nontime-critical software. 
feet VareetlOnS 2n programner productivity do exist hcewever. 


Met. 35: p. 6313 


Research on the man-efiert loadings of medium ito 


Merae scale sottware desv2lcpment projects nas revealed : 
Hesee fiehlOading pattern over time. Pareto, “news is 2 


rise in man-efforz followed by a peaking and <=hén an exoo- 
feeerai tailing off. The time varying nature of a project's 
work prozile is to be expected since software development 


itself is a time dependent process. [Ref. 41: p.128] 


Mensider the tollowing rationale. ApEeSOaewars PLO Ject 
Sem 26 thought of as gsntatiing ¢he solution of a fixed 
number of problems. Ree cacm Pointe in tame, =, both the 
numper of unsolved probiems available for soiution and 
eve Level Of Skill avaiiable for solving problems will 
vary. Boneegen- Lraesce Of proptem resolution is influ- 
eecea DY both factors, it too will be a time dependent 
process. Presumably, consumption of project resources 
reflects the rate of problem résolution, hence, the time 
438479 Mature or tne manloading curve. (Ref. “13 De 
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Be COST ESTIMATING 


1. Cost Consideretions 


A detailed understanding of the factors that impact 
on the cost of a software development project is required in 
estimating its cost. Two major problems are involved in tne 
estimation of software development costs. One of these is 
“he level of uncertainty and risk. The ocher problen 
Maen, Co g Quantitative historical cost data base. [Ref. 42: 
pp. 16-17] 

Tipe ceree as COmeSapute <O the amount of risk and 
uncertainty involved. Thess are that the requiren 
subject <o change, something new may be tre 
deveiooment process, and risks are inherent in 


MevelOpmen= process itself. [Ref. 42: pe. 17 
Ss 


FOC @ gcod scrtware cost estima i 
rem <rirtm requirements, VegerS caro “pae Hequzeec crodcuc* 
well, and carefully manag2 the develooment cycle to |ensure 
nas been 


meee COd:ng does net begin before the aesig 
a [ 


Mioecugnhiv worked out, veriried, 


i?) « 

Ma=TOUCHEEQeCCW rate Measures Or DELOr cos=S it is 
Beememeiy difficult tc estimate the cost of a new project. 
TO solve this probiem cost summaries shouid be archived and 
distributed by the prceject manager of the cevelopment effort 
Semeche appropriate personnel for estimation puzposes. 


(Ref. 42: p. 17] 


2. Key Factors Influencing Software Development Costs 


The key factors influencing the cost of a software 
develcpment project may be divided into the following four 
categories: 

1. Requirement Factors 


eZ Product Factors 


oD 





a Process Factors 


jr Resource Factors 
aw Requirement Factors 
(1). Quality of Specifications. incomplete 
requirements definiticn is a major cause of cost overruns. 
The developer interprets the vague, poorly written regquire- 
Ments, prices the scftware package on the basis of that 
Meer rretation, and proceeds to design =he software on that 
Peme bests. f[Ref. 42: p. 17} 
One of the keys tc¢ accurately costing 
Meee re 25 <0 devote extta effort in solidifying tne 
requirements before Entering the detailed design phase of a 
feo ect. Ure ssearGingd Gwe requirements is =he basis toc 
afalysis of many of the other costing facters, including 
Meee rCuL7yY, ihnterraces, size, tools, use of existing scft- 
Meee, aNd deta pease complexity. Poor estimates of Sortwars 
mee, Or Gc2.a hese complexity are citen blamed for ccs: cvéer- 
Meme, Ween the actual reascn £0r errors in these estimates 
Moe-ncOmplet>S Or inadequate specification cf requirements at 
Maen CuUcSE. OL the initiai scftware costing. (Ref. 42: p. 
17] 
(eee ec ye On Redurpemegts. There are many 
PeeryeCcS LOL Which the well Specified requirements against 
which the detailed design is prepared change during the 
Peegect. Lt is the responsibility of the oroject manager to 
EUily understand the scfttware Zegquiremernts and to ensure 
that it is understood that changes in the requirements base- 
Meme @re just that, changes! The project manager shouid 
shen d*rine the cost and/or schedule impact so that the 
change may be fairly evaluated. If the change justifies «he 
estimated impac* on «he project, Peaccas none to 2nCOLDCras. 
memmay ~nen De Made. The change should then be reflected in 
the requirements specification and incorporated int the 
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design; Po paGlmmOnwe ne | DELO jecC= budge: and schedule 
shouid also be stated. Once the impact of changes on the 
Beoqect is known, Many changes that at first appeared 


attractive lose their appeal. [Ref. 42: p. 17] 


jon Product Factcrs 


Prodyet Lactors are those fectors derived from 
Mramchabecteristics Of the software oroduct to be developed 
and delivered, Picwuerng —bOth code and documentation. 
Pemeoye ng 15 2 GiSGUSSzZ0OnN Of The Six product factors. 

(1). ScCrmwarte S: ze. A very common merzned of 
@eeethig SOLtWarSe 1S tO wastimate the numoer of instructions 
TO De céveloped and muitiplv py a"magic numoer" (Sellars 
Ber 2nseruction) to gst the eStimated development cost. 
Menoudnh this estimating =techrigus is net very precise when 
Meearaicré, £2 Can be yery useful wher used in conjunctior 
Meer che Other factcrs. 

SiG CeEMCe TE SiZimgq considereztions includ¢ 


mee rclicwinc: 


fee carte NUSs= Se *ak=en =o isolate “he daliverab:e sort- 
ware Ero the nendéliverable test soitware, 
Simulations, and support software, which should be 


less costiy *o produce. 

2. As the size of the softwara increases, other factors 
SucheaS COMBLeCXiey, gnteriaces, and the number of 
people involved, begin to have a greater influence on 
che cost. 


SB. When 2£rying tomuse size as a costing param 


D 


Fens b-Cels 


must be taken that the cos* base being used is 


derived from the same sizing parameter. Projects or 
companies may track ccests by lines of code, number of 
Sac ctmeenstructions, humber of ¢xecutabie source 
Statements, Porc PSecnuct=oOns Or iil2nes of code 
developed, GQeeccieVetcamm ns -f5iceiOns of lines of 
Code. 
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When using size/cost factors, COncieerat=onr, should 
also be given +0 productivity differences between 
languages. 

When object code sizing estimates are based on 
Similar existing software, consideration should be 
given to differences in the ¢xpansion ratio fron 
source to object instructions between ditterent 
HOL's, compilers for the same HOL, O= Camesecr an 
operating systems. 


€ increases, tne number of individuals involved 


scones signs icant, daiweng <he cost rsus size 
Sipe oaseseward scne migher multicric. (Ref. 42: 


(2) ee eG) = ¥ 6 One of the nore amportant 

software development costs is the relatives 

MaenCi =v Cr “h= Software application. Soitware personnel 
Meee -i1vity (and therefore cost) will vary with the type of 


ruce and Pederson th 


1. 


2. 


r 
Deme@ete= mined by four mejor criteria. These ara: 
Mf 


being devel oly Real-time applications 
O 


a 
st up to five times as much as HOL 


(2yi. 


Mio wPacagran Mist DEOVIde for continui* 
under nonnominal circumstances; 

weer dcctgs, i<nplemencaz2on techniques, and rotation 
Geeta zed nus= be uni forn;: 

Memnuse Y ctd he required precision in calculations 
ana OUTpUtS> and 

the program must be implemented in a manner thaz is 


understandable. 
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As the level of requirements for nandling 
nonneminal conditiors increases so does the amount of vari- 
mcartion effort required and, along wit fo ete COS ct. 
fRef. 42: p. 21] 

(4). Extern nzerfaces. Cost increases as 
+he complexity of S increases due to the 


ex erface 
additional effort req design, implementation, ani 


equireda fe 
Meecgta=ion { Ref. 42: p21]. 
(5)- Leagteade Rsquisemenzs. HxOGTIShoS aas 


PeOwn <chat it taxé€S an average programmer about the sane 

meeunt of eritor 

language as in an assemply lana 
d 


proc2sss require 


pendent cf the language in which the 

few it «take a programmer significantly lenger to seal rel ae 

program in assembiy language than it would to write the same 
poe Oo esa eG= 2  cyoi cal HOL Statement expands te 


z “ ~ - -~ -— = Roa | = _ 
B-10 assembly ianguage statemen<s. sarily if a project a 
_— —_ ane —_ = ~ bed " Cee eed A - ~ rH vr ¢ ~*~ 4 -_ be -— ’ a 
Mmeeimen's TLamiiaitartty With @ tanguagqe wWiilt aztect ine 
Gos < €r statement mors tnénm tne language being used. 


ents. his’ = COS 
tion and acceptance of 
a 


SoG Oug wit ale 


Gs Process Factors 


Management St releeure, management GO2. 7e lS; 
tools, use of available software, and data base methods are 
all software costing factors associated with the develonnent 
process. A discussion of these factors follows. {Ref. 42; 
pe 21] 
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(1). fanagement Structure. homegenene struc- 
tuze effects the organization's policies regarding the 
allocation of resources for a software development project 
Seat 2s Poze |. Li the structure is such that upper level 
management arbitrarily imposes andards without under- 
*anding their purpose, use, or —egmee on the sottware2 
develcpment process, the standards may prove to be counter- 
BPeocuctive. Management should tie software developmen= to 


@egeriZacional and preduct goals and ensute thet *he precess 
ee 


Memusebieé at thewsworking level. MNO t woo) has S22 uc =ure 
Shouid be such tnat the programmers and engineers ars abies 
zc qet what they need when they need it without the hassis 
Mammav=1qg <0 Get requests througn an inflexible apvvroval 
eno in. 


(2a, se iemeade ment Controls. ies (bacto=: Covys=s 


the cos= of project support in such ar¢é¢as 42S aRanagenent 


Meeco mation processing, S en-au ne Support, aie Clam ead. 
Simp O0OTt. Hee "OS esti march MUS. ScSeaiize Eno nsed for ~his 


ype cz suvvort and have scme understanding of tha relative 
Megas cude of This type of project 
2 


O 
{3}. Develo Boe fas §eceor “at -envzs 


Memaguentity the impact of various development methods. The 
devslopmen= methods cf interest inciud? such approaches as 
mee-Gown design and testing, Structured orogramming, use of 


chie= preqrammer teams, and use of structured walk-chnroughs 
{Ref. 42: p. 22] 


how she software2 will be dev 

and wnat tools will be needed to accomplish these «asks. 
For some projects the development of scftware and hardwars 
megs 2S a major cost iten. The cost estimator must deter- 
Mine whether compilers and ether tools are required, 
available, need to be converted, or need to be developed. 
The costs associated with the tools are a function ci the 
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MeolecGOWPhexity, Use, features, and maturity. Experienca 
prov.des the best basis for analyzing the cost impact of 
PIpPGtt Software and tocls on overall preject cost. 
Reet. 42: pe 22 j 

(5). “Aveitable Sottwars. Sfgnigicare  rbeduc- 
ions in the cost of projects may be achieved through the 
use of existing software. Adapting the existing software zs 


part of a system requires analysis of the software avarc 
W 6 


fron the nz cevelopment. The costs Cemented eV" aS 
existing sortware car in this way oe determinec sunjec- 
tively. Gaeemiccte oe Wicadmen =O > 2nclude the  cosz of 


[meet tac ng ne modified Sofcware to th? new se 
Memo a2cat=ngd the requirements. fRef. 42: pp. 22-23] 
T 


(6). Data Base 


special file access requirements for the data bass are 


v 
maipCr sant parameters in deriving en accurat¢ softwere devel- 
qd 


opment estimate. ae WsGOSt eS ti fa tOae gust review “he data 
base requirements and subjectively analyze their impact on 


Sesc, { Here 42: Dd. 237 


a 


oe rescurce Facczor 


(n 


Software cevéelopmenzt costs for a given proivect 
may vary substantially, devending on such factors a 
experience cf the available personnel, the quality cf 
Meemect S-arf, and avaziability cf developmen= conputer 
resources { Ref. 42: pe. 22]. 

(i). Number of people. With pr 
require iarge staffs the naj 
in productivity (increas 1G = 
needed for communication between «he people [ Ref. 
Zane 

(2). Experience of People. Existing data indi- 
tes that there is no direct correlation between the number 
Ss D 


S 
of experience that a erscn has and his/her 





BEOaduCtl Va. ye However, experience with a specific type of 


t- 


W 
application does have an effect on the development eficrt 
required. Generally speaking, a oDrogramming group will 
mBequire rrom 50-100% more effort to develop a variant of a 

previously developed, familiar program. [Ref. 42: p. 23] 
(3). Personnel Performance. Individual creduc- 
ferpeuy Variations are to be expected in the davelopment cf 
Sigemaue tomer] fect chat 2% is an analytical, and scme- 

a 


a 
Bove w= aGeryity that Eequites abstr 


Nonetheless, experienced estimators have fou ens Vea 
Beoauctivity to bd as Algh as 10:1. The assessment of 
Peeauct.Vity is =xrtremely important because cos= estimation 
1S gen invee Gueccde  tOmeecr: Ving a productivity  Eiqur]e per 


u Cc MEODEMISOCE. P2ESON W2cthin a Given skill category. 

The use of such average productivity figures ror és 

mesa -e1ecS =O Sven Out LOr iatge projects 

Bee aisas<rous for small projects. [Ref.~ 42: p 
(4). aAvailabiii+v of Computing Res 

jme requiremert for compu rey 

Mm vercpment cycle, the impact of insufficient computing 

resources cn schedule and c - 

computer time required for a given development effort is 


easily underestimated. [Ref. 82: p. 23] 


(ye stage pela ty OF Computing Rescurces. 
During the software maintenance phases, when tnere may be 
Meese Capacity available For corrections, moditications, or 
required test drivers to verify changes, there is an asynp- 
totic effect on development costs as the hardware speed and 


memory size constraints ar2 approached which could prove to 
Memccippling {[Ref. 42: pp. 23-24}. A normal person would 
MemeOradinarily jump into a sports car and speed off down 
some winding mountain road he had naver driven cn before in 
Mace Dlack of night. tee idem Wc howe Warning, he could 
PedestMselt at she bcttom cf a canyon, surrounded by steep 


@ierfs, 
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mx ing 


mente and duration. 


dra d.tzonat Cost fs 
ieaaiti.Ona.t eost 


aes. Ze 


Grecacreac 2 


When and if 


procedures begin by 


determining its starz 


it becomes necessary to do 


so, adjustments are made to account for the skill levels of 
the assigned personnel, the complexity of the project, and 
the degree of uncertainty in the requirements. The anount 
nd type of manpower and resources are then converczed to 
Meme = COf#s. Cener cdirese costs, Such eS decumentaticn and 
travel, are also added in. 

[ieadit"ORal COSst SStiMmatang mezhods inelude: 

1. Top-Down EStimating: The estinate obtained usin 
memes Metee@a 2S based one the tstal cost or the cos* of 
ieaieaspe=t2Cnomes CONDletedawerojscts. A problem wit! 
ees Neomedws 2S that it carries with 22 the risk of 
SVieelcon 2G IMpOrtant =cechrnical problems thet may not 
Rew =co@m. )y 2ppertert. [Ref. @5: p. 618] 

Peeeoctnalammcaes and Difterences ssté¢ naktana: ine ats 
method jops 422 obdreKken down toa level of detail 
Miei= "“cne Sim tarities to and airferences fron 
previous projects are MmOSt easily reccoqnizabie. 
Maese SUnics that cannot be compared to previous 
projects must be e¢Stimated Dy some otnasr means. 
(ket. 355 p. 6 18) 

ae) 6«Ohact vO’ Estimating: 

fieomesteMeacOs ==126¢S on sensitiviz~y, coefficients 
Se exchange ra®ios that are invariant (within 
Mies towne details of design. The software 
analyst estimates the size of a module by its 
Rumber of object instructions, Geass. fies 2% say 
type, and evaluates its relative complexity. An 
apeEepredace COS = Matrix is construc ie Ge Omid 
cost data base -n_terms Ome Gost Rpoe ois eae Ol, 
for ‘that type ci sortware, that teiative 
complexity level. (ROT .£Mo D> Dips “6 18-619} 
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cr resources consumed in one lifecycle phase on subseg 


for any one phase derives frem the ways in which ¢<h: 


ey) 
tn 


j- 
i 


f-> 


The appeal of using this method is in it 


Ss 
simplicity, speed, convenience, and usefulness ina 
Variety of environments. A major shortcoming is in 
the lack of @ valid cost data base that covers a 
number orf estimating situations. [Ref. 35: p. 619] 

Standards SZstimating: Tn Standards estimating, 
Systematically developed standards of performance are 


depended upcn. New tasks are calitratéed fErom thes 


a 
edly performed Operations that have 


peen weil 
GecuNeneea. | Phe £UD is that che same software devel- 
Opment projects are net vertormed over ani over 


aga. ken. 352. Dp. 619 | 
Bezttom-Up Estimating: Government researca and davel- 
Somene CONTLACES 25feG MOST gener 


a 
we DOLE ON-UO epptoa ch. A WOrK Dre 


: a bed * e 3 -~ a ane: = = a 
She project until 1= is reasonably obvious what steps 

a ‘ = ae eos AS = — ~ ‘ - aa mn ~~ =~ 
aria fesoOurces are required for Sach task. Pes eeles 
ate =tnéen e2Stimated for each task anda vovranid is 


a 


developed to 


e 
Using this czec 
= 


4 


s 
hnique, the estimating assiqnmen 
be given to the people actuaily doing the work. One 
DeebvenN Witt chis tTecin2 que is the inavailapility of 
Pemieorcl —COst S=tuSture at =hs inception of the cost 


oe Maer ng JOD. FREE. 35: p, 619] 


Coss ie & ities 1d Relationships and Biyese2 
iimenme tac2onSsh: ps 


S@a=ewWweat= COSt @CSzti mations Should include the eifects 


u 
Mets edesCou eS. OU2 20M GO =he Tesource requitements 


n 
aze¢ conpleted. Sie nDOneaitaracsor affecting the 


EreeOn OGL GeCSOULCeS iS the need to conforn <“*o0 4a 
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deveiopment plan. The pian is an essential management *ool 


% 


aVailabie for <h2 


(b 


ror Ensuring that the needad resources ar 
eo qect a= the fight time and in the ccerrect amcunt. 
Changes in the plan, whether caused by changes in require- 
ments or by failure to meet commitments, may affect 


cost-driving parameters. [ Ref. 43: p. 70] 
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V. THE AR 


AND SCIENCE OF SOFTWARE COST ESTINATION 
Until absolutely reliabie, comprehensive methods of 
Pees mtating cost and effor= *#n software development projects 
are developed, the techniques will be referred to both as an 
art and a science. We aporopriately use the term science as 


estimating techniques are becoming more and more accurats 
Gc 


and comprenensive. Mach=@aceCal ead SC2entleaic principles 
Meena ncreaesingiy oSing applied to ail areas of cos= and 
aeeorLt €Stimation. Researchers are now develionving medels 
tnat can be used in numerous E€nvironnencts. 


Ae CURRENTLY AVAILABLE METHODS FOR SOFTWARE COSTING 


Meetct tcdav and adSnerally cover the tine from the design 

Sees tecli-catacns shase <inru the test and depudq phase ani 

Memeo -Ci foo ng Of Crerations. YTney can ordinariiy be ciassi- 

mood 2S ReOectvca i Cr CMD = cel. Pee OsS- cca) 8O0s'S ars 

those based on giobal assumptions such as the rate at which 
fo) 


people sclvé probiems. Pirated models use l'information 
from former projects to evaluate current projects and ijierive 
bkasic formulas from the available information in the data 
base. [Ref. 3: pe S17} We will present a number of avail- 
able cost and effort estimating models according to their 
Classizication as static, dynamic or dynamic transportable 
modéls. We will 2xamine some mod2is in more detail than 


cthers to give the reader added insight into the complexity 


Seat Mating CoSt and effort. Some of the more sigqnificant 
meemeire> of the models will be pointed ouc. We will then 
enumerate criteria which may be used to judge a modsi for 


estimating cost and effort in software development projects 
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Modeis that do not treat time explicitly and deo nox 
have the capability to adapt to the actual behavior of the 
system atany instant of time durin the lifecycle are 


termed static models. 


The Doty model estimates the manpower, cost and 


devsicpment time for sortware cadeveropment projects. Systen 
eee- iS estimated by comparisons of the system under consid- 
eraticn to comparable knewn systems. The model is thareiore 
empirica.. Dear OUnGee Haemeecne Wootang of high order 
languages (HOL) and assembly language instructions tak¢s the 
same amount of time. Since HOL programs are smaiier than 


assembiy language prcegrams, productivity is increased with 
HOL programs. Graerety and) “Gfaintainabili-~y afe hichar with 
ome | REL. 2: pe 108 ] 


cea wsercos.! 


Pees eCCOMrec on OL <he need to €stablish acod 
cost é€Stimations before proceeding on a software development 
Bao ject, Grumman Aerospace Corporation has developed an 
Pemcr cal medel to previde viable, credible cost estimates. 


Before completing its own model, Grumman used the Price-S 
EaetO eStimate costs. Paesenety,  oeen the “SOFCOST" 
G2i and the Price-S acdel are used in parallel as indepen- 
Mame COSt sStimates to act as checks and balances for 
estimates of the project system analyst. WSO CGOS. "al Lows 
the analyst to estimate the effort and elapsed tine to 
ccmplete a software development project. It is a parametric 
mega. Geveloped from Statistical software history. aes 
Seeeeetcal model uses for its primary parameter functional 


size. Tke basic estimating relationship is influenced by: 
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learn xpet ence 

pe econo lexi ty 

Bae Environment 
4“. Technology 

5. Hardware 

Se reliability 
7. jQxLanguage 


8. Pequizrement Definiticn. 
The model opetatss 2nteractivery with the user 
Seme@eVelicp a SOLtTWALS FOIK opreakdown structure (SW5S), 2 
mre r acral size matrix tor the SWBS and she time ardG effort 


@emput=c for each item in the SWBS. 


ihe r= azo five; levels co the SWBS, the computer program 
merc. dtibation™ iten, os Sa ecgic ays of S@meWweane, Che. Cunc- 
tions per category nd wo output levels - task and 
phase. The two S50 me tavels provids the manpower tasks 
Pe tschnicai, support, mana eMmenc, Coe uma OCMeCuEr GL 
n _docume entation per deve opment Ses Qn 0Ch apes or 
cgds = as na aCCEps ance for act 
ce See Se Svsten computer 
d v-ovided aS QUTPUt. 
pee came | sscheduis, Ree 


iH 
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4 


3) 
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Grumman's research included 30 diffarent medels 
and a review of research ccnducted by industry and govern- 
ment. The work resulted in a requirement and design 
document for an in-house model. The model net only included 
PaeOos SOLrtWare/cost relationships but also charcteristics 
unique to the Grumman envirenment. 

Research concluded that the primary cost driver 
2s executable lines Seo etmc a COde ss SOreOSsi"swasc theretore 
designed to aid the user in estimating the rumber of lines 
orf code. The estimator can make comparisons between his 
Mijetson ana comparable functions found in the data base 


eaeeuding function nad size as its «ey parameters. The 
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Pe penilinataon On Size Of 2 Eroject is thus a critical factor 
and one that is addressed using “*he judgement of ths 
analyst. 

"SOFCOST"' has three objectives: 


lace CONnStrucc aneswvES, 


Ze. to,determine a credible size for the functions 
being estimated, 

PO oem SO GUN dee Coe seid schecul= ior each 
SM@eCE® Chal =ask. fRers 44: p. 674 } 


As is becoming increasingly common in iiterature 
Semen e =COLC, Grumman =sels that the itnteractive us cevel- 
emma al €Sclimate £f£oOr cost and eZfort for a project shouid 
be knowledgeable in computer softwar2 design and the partic- 
ular system's requirements. The SW38S will be established in 
an interactive session. Mercere Sehe rfive levels are 
Memqeme Cc, whe USer interacts with “the proqram to answer 
M@estionS =hat affect tn2 Oasic co GCMPUszac1On. -COSts aze 
@eveemh 25 Mankours cr menmonths and elapsed <zima echeauies 
az= dispiayed. 


d 

Tranciesees 1 eStabliscnes the SWSS. Troanslat 
a 2 

fe) 


) 

ze estimate for all functicns in the SWBS 
u Roeeomne COlPs Facile Nature fron the d a 
Translator 3 of the program takes the output From tr a 
2anhd computes manpower effort and schedules el 


a 
femeesenere that the estimator begins to interact t 


Mine the adjustments to the basic eStimatées. Languace is 
eies< considered. Prior studies showed littie ditferance 
between productivit Or HO LE. Deber pee, Ces. cceuLLed ir che 


productivities of HOL's compared to assembly language in the 
ete GeO= 2 Of 3 tO 1 Improvement in productivity (this is in 


keeping with Doty's findings). 
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Paeee Panduageo type 2S estabimshec in Translator 3 
ar adjustment made in the size cf the source code 
tr language the basic manpower versus line of code fcr 
Sélaticnship in the mode is exercised. ser Cost,! 
computes the effort for the phases of design code and 
test with a parametric equation for each. phase. The 
effort computed during the design phase includes those 
Seeps in he sortware development cycle of requirement 
@efinition, preciiminary design and detail design. The 
codé€ phas@ equation output includes coding, debugging 
and module test. | The test phase effort aincludes 
subsystem, system, integration, and acceptance testing. 
The equations for the design, code and test efforts were 
regressed from historical data oublished from studies 
Senmcuc-2d by SDC, GeO, TEM and TRW ana from actual data 


Phy a 
O SFA 
uct 


peEocuced at Grumman. These reqressions when taken with 
fees coos CONDizac2O7S OF the i dDUdLished scurce dara 
oreduced correiaticn coefficients in excess of 854 waren 
mMenverted ©O the log-linear forn. The F vaiue measure 
Sect aciseical ececcpradiiicy based on the numper of 
Qbservations in the regression were on the average 
Meeadt cs team 200 and indicativs of regqression sidqnifi- 
@once. [{ Ref. 44s p. 677 } 


iisomeee.Otanese then Detfomtned =o adjust <=he 
Me=s2c computation effort. Thirty questions are asked the 
user and he evaluates each on a scale of 9=0 410. The 
Meou-<~S ari used tc Comat amor cOUGea vey index Factor. 
Adjustment Teacezors 222 con puted nem occ n question. 
Meeavicua’ adjustments ars weighted. Peo si lists *he 


a 
[eee ce =ne indi 


{+ 
fas 
iw 
ey 
}— 
rey) 
ey) 
ES), 
[ aw 
WM 
ct 
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J 
ct 
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ow) 
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O) 
ct 
w) 
O 
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0) 
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answered, 


ites "aaquusced efiforzc is then distributed among the 
Poeses Of dectinition, design, development, test, inte- 
Seeareon ana acceptdnce in accord with the results. of 
published history. (esse ee e. Vaeee .1 On gon tie Standerd 
#O-20-40 allocation. |. This adjusted ccmputed effort 
- Se ee wae technical efrort expended upon ithe 
ambedded program (appl 2cat ion, = aee eal) by the 
personnel assigned as pregrammercs, analysts, systems 
Beogs=neers, etc. i Transiator then takes this computed 
2ffiert and determines the support, management, and 
Mere gurd-20n/Quelicy contrcl etforts as some function 
Seeeene <wechnicai effort. Both the documentation and 
CoOmfuzter resource ¢frorts are computed separately using 
Seepalream2tric Squation telationship fcrmulated ztor tzhese 
tasks. f Ref. 44: p. 678} 


70 


(iD 
ie 





S.C i ess 
: | 
| TABLE If 
i Adjustment Variables by Decreasing Weight | 
| 
Percent of real time pro gramming design | 
| Percent of new aigoritan design | 
fee ercen. Of existing code reutilized | 
| Percent of requiremen=s i11i-defined | 
{ percent of time share facilities employed | 
f Rercent of. pushing Ehomeieate GF tne art . 
eUdoct Of -nNterracing displays | 
| Number o= interfacing «quip excluding displa; 
Meee ScCent Of user experience n | 
Meeecrcent Cf concurrent SG ah ey Sa Gévelopmens 
fee eo ceh. OL Cocds inspection technique mployed 
Mtoe eCan. OF Clabde anticipated for the. me waaqn 
| Percent of top dcwn design employed . | 
fees ccen= Of Computer time utilized as a design goal 
Meee coCeh. OL Security in design . : | 
Meee cCen. Of Ser Uuctured programming employed { 
[eee GCen- OF INPU=T/OUTPUS CCHtfci progEamnhing design | 
|} WNumper of average years experiences of oersonnel | 
Meoscel. Ce Dioe@ViLCUS 2xperlence with che computer 
Meme ecoee Of application/iuncticonal experiance 
| Percenz of chief programmer team technique employed. 
Mueerse- = Ch MeMoOsy Capacity uzzitzed as @ design goa { 
i Number of _progzra mming LOCa= Ons 
{| Percert of software personnel experience 
{| Numder Se TK SOE ee In the computer ser 
eee ecCe l= OL Megat = 5 cnc = 
Meee cent «CL See Pmelceetper tence Wich Similer algorltams 
Percent of user defined requirements alone | 
Meese 2gG=t Or the compute= 2 nstpuction word 
{ Percent of cae oS Mee Mees sece cOonplexi 7 y i 
{| [ Ref. 4&4: p. | 
| 
ee ee ee eee 
For scneduling, elapsed time is computed both as 
meeeunet en of he computed manpower effort and also as 2 


eUnct=On of the adjusted lines of code. Start and and dates 

are computed for éach phase. An Se otemezec Schedule 2s 

Out pus and difrerences between planned schedules and opti- 

mized schedules are highlighted. Requirements documents 

usualiy dictate planned schedules and recognition cf accel- 

Tations and/or stretchouts that maght happen if the 
fo) 


planned/con*ract scheduls were £ 
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Piste SOrPee@sm uses historical deta and empir- 
ical data from the environment to develop estimates of cost 


in manhours or manmonths and scheduling for various pnases 


mea PrOVSct. The interactive sessions with the user allow 
a mere clearly defined SWBS. The primary cost driver was 
found to be executable lines of code. The paSic computa 


tions are adjusted by an interactive session with the user 
Mmam@noch Sivecific envyitonmentai factcers are evaluated ana 


BescOunteda “or. 


Mi micCevmeEcermens then. s Model what are critical 
Pee Go Mae son Elreg=ss  e€2S Zhe initial sizing of the 
Beojec= and the determination Of unique environmental 
Meecers =hat arztiec= costing and scneduling. sg a ake ness ie 
Seese activities, =zhe judgement of the estimator as he 


Meee ac eS With the computer is critical to tae success of 
mee DLOject. 
Ge) eee cyoG = COS = EStinNa zing 

whe. DGeROn-wUp C=compos. t20n methodology ard 3 
mee=-iCWwr i reqresston analysis is used az =he conceptual 
requirements level to provide fast and accurate estinates of 
Beeewoare lifecycle costing (LCC) employing unique seftwarea 
Sere ur éS. Tit SCteWware “Structural model is further 
analyzed and manipulated to give useful désidqn alternatives 
Meeeecon= cOrm of SUCcCh criteria as @egramt Cont t OL, ieg2c¢ 


patns, and data transfer that improve she operational gquali- 
miles Of the software and prcvide gininun LCC designs. Tass 
~echnique seeks to obtain a uniquely tealizabie decomposi- 
On Strategy and finally give a machine designed 
@eose-erféctive software structure. Suveyer feels “that the 
Current method of using an empirical top-dewn approach and 
multiple regression analysis employing extensive data bases 
Bemee- Mate scfitware sizing and costing is unsatisfactory. 
The uniqueness of each software package precludes his 


approach. 


Te 





The cCveraii problems of program. management and cost 
@enasol, as well as the _seisction of cest-effective 
design alternatives are addressed by using a_combined 
Graph Theory “bettoms-up" decomposition nethodology to 
provide accurate and rapid assessments of both technolo- 
qacal feasibililty aimee ecCnomsc Ta SKS ihn conjunction 


feeen 2) =| 'COpSs—cown" regression analysis employing cost 
eacima ih hegatzonships ~{CERS). At the  sottware 
requirements and conceptual level, structural decomposi- 
OD ~dentifies CEitical giolestones ene 2xposes 


Subsequent cost drivers through the specification of 


connectivities and paths which yield mininum Life Cycle 
Seas-s (LCC). Disoe ee osrececorpeo Sneed by Utteezeng the 
pete ce 2 8, Of aggicomerative po1ythetic ciustering to 

efine a topology for determining chjective deccmposi- 
eon Scrategcies Eelated te computer software structures. 
THe Mathematical baSis £¢r mapping the software struc- 
muss OneOQ € Perr cular gtaoh MScric space is discussed 
Memeicome Of EODNU Mating 4 gquelaty index tot oanerationa 
Semele usa! Dab icionring. The ‘use cf vo zsential mulri- 
[eaewesetce SeNs-Meerzcs is illustzeted with a viaw 
Towards obtaining an optimal, decomposition strategy and 
uitimately provide machine go COSt-Srisective sott- 
Were Structures. [f{ Ref. 45: p. 665} 


Silver found that the traditional metheds fail 
tO provide a comprehensive and useful software management 
Somaur.Or that naS termS that are functionally pie and 


n Separabi 
indépendentiy linearly related to system gu Ss u 
sile struczurs, memory requirements, and number or afpiica-~ 
mon Crograns. Dceweoqiac Obs are all =cc 
Memeo we ject i v= EXDle Cr the eStimatc> i135 not accounted for. 
Seeve= £2els that the top-down approach does nox aqive <=he 
Meee=saty eccuracy and certainty of estimati 


C 
Peiaustively useful in estimating cost and effort in soft- 


wars developmen*> projects. A methodology shouid gqive 
momiracy anda certainty early in the development precess of 


the cost and effort involved. 


"The assumption is inherentiy made that attri- 
butes of design quality at the requirements level area 
Sueeeeciet tly Man rest in the structural characteristics of 
Beemoss. 9d) process itself, so that hey can be costed in 
detail. Furthermore, che analysis of a give software 


e 
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n 
Semue-UufS 1S an appropriete vehici2= for cemparing difis 


ie 
SaeeacegiesS On 2 cost-erfective basis." [Ref. 45: p. 667] 
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meen in the effort multiplier 


Systen evelopment cos= is generally 


PeoecesSC= capacity is availabie, Sspecrally for virtual 
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e. TRW 


The empirical TRW-Wolverton Modei assumes that 
the total effort exerted in completing a program is iinearly 
Peomortional to the number of instructions to be produced. 
The fclicwing is used in this nodel: cost-per=instruction 
MewetXxX, Organized by software category (control, I/0, pre- 
processor/post-processor, algorithn, data management, anda 
Meme —Crizical) and deqres cf difficulty (old progran- easy, 
medium, hards new oroqram-easy, medium, hara). Ve as 
Seal cOMEuUtSer uSage Matrix is Kept by category of software 
mo =eSt_ma-e the cost cf computer time ne 


= 
[eemiec COS=t becomes a product cf cost per instruction 


mee ecreojected number of instructions to be projuced. 
WOlverttorn has neted in his analysis that past experience 


Mees 2Ot impact On programmer productivity significantly. 
S4E€eOr —=2€ SSEimate iS a number of 
9 


Se Seawoudec. VT ASaruction as: <4 


Meme Ce )6| 6UOflCU URS h6C6UPElative degres of G2Eficuitzyv (0-100), 
Spee yee Sapo l cece = On, and type of project {f{Ref. 32 0D. 
Bz]. SOrctWware 2S Broken iktO parts and costs esrimated 
individually in the best use cf «he model. Wy SS INC Ce aa" 24s 


well-calibrated *o aclass of near-real-time government 


Semmanag eka control projects, but is less accurate for 


th 
O 


wm 


m 
other classes of projects. In addition, <he model provides 
a good breakdown of project effore by phase and activity." 
(ieete 32° Pp. 513 ] 


2.- Dynamic Models 


se ee SP oS ae ee ee ee 


Thess models us2 r2al time input and indicats where 
Semeee NOW and where we 2re going at a particular ins<ant in 


Ime . 
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aw TRW (SCEP) 

Ricwe ue VerKne Ss Orewape COSe ES<atetang Progzan 
(SCZP) was developed by Boehm and Wolverton. This neod2l was 
developed using the set of criteria presented later =o eval- 
uate software cost estimating moieis. Comments on this 
modei‘s performance according to the criteria set fortn will 
be given later in the overall anaivsis of the modeis. 

ae Nel ScOn endahe! 2 xStodcel 

This model qives a metnod Ee “Saale ©2215 
programmer DEOCUGCHEVaSy. Proqrammer S2Cdleeay Ley Ss 
feared 21 the rate of oroductzion of lines oF code (LOC). 
Meven am “Stimate of the itnes of code to be produced, <n 
Me@el =eStimates the total maa-months of eftor= required. 
Men=mern=hs become a@ function of *he LOC t°0 be produced. 
Mom sh= Cate base cf IBd4-Fecerai Systems Division (IBH-FSD) 
M@em@ensc. hd Of o0 Drojects f Ref. 3: p. S06], & SEt oF Trela- 
“2707S wes déevelooved eo oe ised Zor GGst “estate 2G: 
Beecesses, The relationsh:ps are: 

ioe DEOaCUCELVIcTyY VS percentage of new ccde 

Seeemesocuctivory VS percentage of effor= at primary loca- 
2ZOn 

Pe PLeductwavity vs percentage RJE use 

GY. delivered source documentation vs delivered code 

5. duration vs delivered code 

eee aura=2On VS total man-month effort 

See Sec=2 Si Ze vs totai effort 

ear Gemputer cost vs delivered code 

pee CCMpUTEe= Cost vs *otal man-months of effor- 

The main problem with the model is the diffi- 
elt ye 22 determining how change pee che Seen GS 
Me@aucti:vity of cost »drivers is due to other correlated 
moemmoes Of DY double counting uSing four factors *o account 
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manpower, understanding exactly what *he software develop- 
ment process consists of over its life cycle, azaintaining a 
Geeta base that reflects th history of actuai scftware 
development costs, and developing the mest cost-effective 
allocation cf resources to different phases of software." 

[Ref. 2: pe. 106] 
Puznam has developed Monte-Carlo simulation and 
linear programming to as<inate development time and nanpower 
m the trade-off law in the systens definition phase. 
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future resource allocation during the dea 


computer usage and resource allo nd Ge 1a) .0/ = paireinc ol ep ot 
and maintenance ponase." [Ref. 2: yp. 106] The SLI“ nodel, 
eae wpceted version of the Futnam model, also has the abili- 
mec CL €Stimating computer costs and using th] PERT sizing 
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transportable models. Thesé modezis can be ¢volv 
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merlec= specific environmental infl 
Ae Meza Model 


The Meta model is an empirical nodel based 
Primarily on the work of Boehm and Walstor §& Felix. Th 
modei permits the development of 2 rescurce estimation model 
Memmany Paccticular organization. The model itself can be 
used from the beginning of the design phase through accep<t- 
ance testing and includes programming, management and 
suppert hours. Effort 1s expressed 2s some measure of size. 


Deviations from the average are explained by environmental 
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Mera" eutes Known £Or each project. A background equation is 


computed, environmental factors analyzed and the model 
Baodgiccs ELtort for the project. A size measure is chosen 
from available daca. Estimating size for each project is 


accomplished by taking the total number of new lines written 
and adding them to 20% of any old lines uséd in the project. 


A base-line relationship of lewer standard error is carived. 


The size measure is called deveisved lines. Develoved 
modules is arrived at in the same mannér. BeOS Lees 
acasutéeéd in man-months. The Meta model is employed as 
ecilows: 
1. Compute tae background equation 
Peete Ee Memml eC. G5 eVdilable .to explain the 
Peace wemlec Dewwes,  accual esifort and eztcrt as 
predicted by the background equation 
Be USs-etnecemcac! => predict the etfort for the new 
projec=. [Ref. 46: p. 108] 
Golieee srg data about the ervyireonment is done as 
moti lows: 
1. Choosing a sét of factors 
2. Grouping and compressing this date 
Cwepececlataing “che inportan= factors 
ann COED OLa: ng the actors by performing a 
multipie. regression es SOUmee es t= GeVla.2Ons OF 
=h 2 points from The EQ pus-ed base~line. 
fRef. 46: p. 1117] 
a Oe 


As a rule of thumb, 10% 20 S54 cf tne numb 
Gee DOINtS shoula be the number of e¢nvironmental fa 
used to predict a given number cf points. The 
collects data froma particular environment and 


daza to make predictions about the environmen. 
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Good managers can usually estimate the cost and 
PeeOrt Of a sOftware development project better than tke 


Meec2cciOns of a model brought in from another environment. 

The expectation is that this model wili assist <thos2 

Managers in making even better predictions concerning cost 

and effort. The Meta model is developed by duplicating the 

Besic steps of the model with information from a uniques 

environment. The nodel is molded into the environment which 
n 


SQM oO NPacecCOnTOde = =Hpe | nev 


Mee use it and no= simply tu 

environnent. The model 1tse2lt is pased or. earilier works by 
Waistcn &€ Felix and Boehm who attemoptec to relate preoyect 
Beeze to Effort. Measures used tO express size in the Mets 


- Lines of Source Code (LOSC) 


= 
1 
2. Executable Statements 
eee Machine “fnstructions 
uu 


a Number ct fodaules 


© 
base line equati 


4 Of Jomised ba CONJURCTLON Wihea 
Mmeeyociial a~tributes of 2 prcject “hat afiect the base lina 
Souaclor. poehm and Walszten &§ Felix kav2 suggested similar 
modéis. PoVveEnOnriencc! d2:Efesenrces wxplain variations erom 
the averages arrived at by various equations. Environnental 
ditferences are accounted for by a number of factors suca 
as: 


1. Skill and experience cf the programming team 
Pam USE Of good programming practices 


Peeebeatltculzy Of the project (conplexity) 


A eWwO step approach is used to develop che 
model. 
1. Erfort exerted on an average project is expressed as 


eeuune. On OF S1iZ¢. 
2. Deviations from the average are attributed to envi- 
ronmental characteristics. The background equation 


is derived from the relationship between effort and 
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available. 


The use of the model is as foliows: 


1. Estimate size of new project 
2. Use base-line to get Standard effort 


3. Estimate necessary factor values 


4 


Pee onm= = ds2rerence this project 


sh 
AM 95 coche 


See Divercna. Giicerencse to standar 


[Ref. U6: p. 114] 


The main difficulty with the Meta medel invelves 
Meme rytrg Signaricen=t environment2l factors and deciding 
Powmid:y =O US@® in the estmating proces feoves PEL. wes 
Samey include envircnmertsl factor Beet tef2ecQ OY Wakstcn = 
eotix, Bcenn and those .denriGied «et the Scitware 
BPegeneeriong Laboratory 27 =he W“ASA/Goddarad Specs Fiigqa- 


os oo ~ ~ bette gs ~ oS. aN ot iy pe an ~ ay oS a Ss 
Me@cee@r wnere pelley and 8asiirt collected the data to Eenon- 
= — j- cere . nt 
ec a t ei “Mesa model. Geom an, & Veet VtCuLer DES jece, 


Beeeerchers thought to have influence on «he eficor 
Meta preject, 21 were selected for analysis and group 
aia Na jCr Ccateqor ies. EmeatCte ng @ Vertiabl= with a few 
Meee oCen-S (18) using many factors is not statistically 
memed., The problem with adding the ocints o£ 

Mma 2901 Cated ite influence andusing ¢t 


« 


Meeeuet.ce Of that category is that some individual 


Mia May be very influential lose their identity. Two ways 
aeound ~Ais re to use more data points and evaluate cach 
attribute independently or te determine the relative affect 
of each attribute and weigh them independently. Bailey and 
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TABLE LIL 
Evaluation Factors - SEL 


Program design language (development and design) 
Formal design review 
Tree charts 

Design formalisms 
Design/decision notes 
Meek-caccugh; design 
week = = chrougn: code 
Beco, soe 0ing. 

Bop-dcwn design 
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S PEuctu=ed code 
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See211 did not have the requisite criteria for either solu 
u 


zion so they used the described method of qro 


+4 


ies Price=-§ and Price-SL 


ay) 


The Price-S and the Price-SL are empirical 

s developed by RCA and can be used in conjuncticn to 
te tne software costs during a support period for a 
ee cecyect [— Ref. 47:3 pp. 663-664}. ie. 25 2 Ge- 5: model 
ses a tcp down approach to determines the resources required 
@ sottware develcpmen*+ project. The model delivers co 


S 
@eamscnedule for sizes, type and difficulty of the subject 
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TWELE LY 
Evaluaticn Factors - Walston and Felix 


Custcomer experience. 


G@leeOter Dabttcipation in definition 
Customer interface conplexity 
Develcoment tocation, 
Petcen* programmers in design 

~ogrammer qualifications 
Senne s experience with machines 
Prcqrammer experience with lanquag?. 
2) (oe gamer an op Skee Cemsg on ADpLLCa ttn 
actked toge et aer on {5a a¢ type Of brobien 
Miescomcr Obi d22ated peogztan design changes 
Hardware under G Sy eloone ae 
Develoement environment eee alt 
Development environment With request 


Develcpment environment open 
DéEvVelopDMent environment 
Development environment TSO 
Petcen= code structured 
Percent code used code review 
Percent code used top-down 
Percert code by chief programmer teams 


> woos OE gure GE oe ORS qoute OC dienes SI age eee GE ie SE ee eae qo epee Onn ED ees aunties OED eee 


Unclass: fied 
fRef. 46: p. 112] 


ee et SY ee OD CE TR ea CR eee SE ee ge RR gy ee ee oD ot ee OE eee a 


Momplex=2y Of application processin 
Complex=* OE program flow 
| Compiexity of internal ccmmunication 
Memeconpiex- =y cf external ccamunication 
[Meco mDieX: ty Cf data-dase structure 
Meee oe. «€©6COde NON-mathn and I[/0 | 
Meee Cet: COGS math and computational 
Meee = C-2= COdS Cel and £/0 cor<tol 
Meee rcen: coce faiinack and recovery 
{ Percent code otner 
Mereocvoporticn code real Same tOk Mhecsacsi ys 
{ Desiaqn const rar Mess ae Nstorege 
| Deszgn SOusmaeNtSes Tining  . 
| Peete Oloema nts: £/0 capandi.it 
| 
| 


Peo gect. the Price-S model uses inrormatica from histerical 
data bases to estimat the costs o€ a néw projec. The 


Price-S model gives information about the scftware when it 


1s installed for operation. The Price-SL nodel uses infor- 
mation about the environment to estimate the cos to be 
meeurred Guring a particula= support period. COupD a ng 
these two models, we arrive at cost estimates up +o a 


particular point in the development phase and throughout a 


feven SUDPOrT period. 





TABLE V 
Environmental Factors - Boehn 


Reguired fauit freedom 

Data base size 

macdte: complexity . 

Adaptation From existing software 

ex =euczOn timeoconstraint 

mn storage constraint 

ee machine volatility 

uter tesvonse time 

“Yoo Capability 

Gaz ors experience 
Pecarammer Capaoliity . 

yoet ual macnine exrerisnuce. 
Peagrenning languaqe experience 
Modern PLrOGramaming aos 
WSs Co SOLtWwarte too 

Réeguired develo oe chéedule 

fRef. 46: p. 112] 
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» Development Schedule 

SeCrcwwWare Size is measured in the number ct instructi 
Application refers to the type of software being dev 

Peeercrem rerers to the 2nvironment in which the 
cperactes. Development scheduie 1s self explanatcry. A 
development schedul? is computed and compare n 
schedule and the degree tc which the de 
normal, accelerated or stretched out w 
Pree sepeair activity. Accelerated schedules will 
cos<iy and stretch2d out schedules will cost less du 


€xtra time to develop better quaiity software. 
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(Nn 
re 


Ss two primary ee 


A 


The Prace=Sl identitf: 

drivers: 

le) Ssuppoest Scheaule (SSTAKT to SEND) 

Be Growth Factor 
Shorter schedules will see bugs more quickly found but a 
lower total number of bugs. Shorter schedules will precludes 
erhancements to the system and the anticivated growth factcr 
Will probably be Lower for short scneduiés The number of 
Meoca tations and =he ameunt of average usages will attect 
mre Number of bugs found. Meee negneh eacisl O= TheS=e, <=2e 
more cugs. Other SUppor=t economic parameters are nediriesrs 
Seeene Calculated cos=s and include multipliess fcr suproret 
marck-ups and suppor escalation. 


Gegesr £Or THe  Price=SL are cétegorized as 


En GOW Th 
Meee were COS-~S aze 2Stinatea Scr “he Following Five elements 
Mesach Category: 
1. Systems Engineering: Seeiieeoat tasks “SE TNE Ernire 
seftware system such as updating té€st dlans and t2es* 


2. PrOgraenming: Coca eOr MD VeMetmeeea cesign anc cod¢ 


changes. 


Bree Been raguzaticn Corto ls: cost cf maintaining syst2in 
integrity and determination of system baseline. 

4. Quality Assurance: COss of maintaining systen 
inteqrity and determination of system baselines. 

5. Documentation: cost of all changes needed to support 


Maintenance, Enhancement and Growth. 


6. Program Management 


Costs on a yearly basis are provided for the three major 
areas cr the five elements. The Price=-S and the Price-SL 
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models are available from RCA and can be used to estimate 


cost in varying environments. 


Gc. COCOMO 
The COnstructive COst MOdel detailed by Boehm in 
his mest recent publication is a most powerful instrument 
Meee eStimazing cost and effort in software deveicpment 
GE 7ec=s. The more detsaii that is provided as input to 
GCCst EStimation model, the more accurets the ¢stimates wiil 
Boobpatiy be. MieeecCeno MCCS. et LONS The DtSsrEeratlon oF 
estimates in gocd detail an specifies and process:s5 then 
Mean COnSidéerable efficiency. Mie fees e=derors inpect 
eos: 
ecco ceOri Ver? Product &Avtributes 
Seow Reels Sed Sofavare reliability 
a) Does tne software perform its intended func 
© LOns cover “ne next ieee ae 2 OD anc 
Subsequent utiliizations? 
=) DATA: Data base size 
sie Ge 0-5 Wace product complexity 
Pee CCS. DEiversc: Conp tributes 


Qe lies  =XecCutz on time Constraint 

Bymot ORs) Main Storage constraint 

Gyeemrats Virtua machine volatility 

d) TURN: Computer turnaround tine 
3. Cost Driver: Personnel Attributes 

GyeAGAP2 Anal ys<c Capability 

b) PCAP: Programmer capability 

C) VEXD: iriual machine experience 

ad) LEXP: Language =xpeéerience 
eeececs. UVitvVer> Project Attributes 

ap SODP: Use of modern programming practices 

BE) TOOL: Use ci software Zools 


c) SCED: Development schedule constrain: 
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Hemant Chica decomposi=20n is used to aid in 
producing cost estimates. The lewest ievel is the 
Gost drivers that are described at this level are: 
complexity and adaptation from existing software; progran- 


mer's capability level and experiences with the language and 


V2rtual machine on which tne software is to be built. The 
second i¢evel is the subsystem level. A MUnNber Oem, cose 
Qtivers affece tnais level. Tne cost drivers vary from 
Mesyscem =o Subsystem but are usually =zh= sane for 2:21 
Meeukes In =~he partticulas subsysten. The top zevel is tn¢ 
sys7zen level. This level is used ct Doay OVeGaAadi oro yec= 

1 na se 


= a a aoe Ree Oe —_ a ee — ee eee ee ee ee ee 


scltware cost sstimnating nodels can be evaluated. 
W 


ieee Del inet coer : dOuewWo irae scstand iicom =he model whez 
Scere itty is estimating and what costs 2c. Gis 
=xcludang? 

yee PLO SLTcy: do estimated costs compar2 favorably with 
dere dal Costs ? 

Bee ORVECCIY ity: See UUGCSt ars yers Eelated to factors 
that are objectively measurable and not cpeéen to mani- 
Dulation to get what we want? 

ee (6ORStLUCtLVeness: is it clear from ‘the medel why a 
Pe@leemedlas Sf2ite t= 1S arrived at and is the software 


project more understandaole beacause of the model? 
h 


ciently breakdown the 
= 
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oe Stablia=y: do smail input changes produce small 


output changes? 


Fie SECO DES is the model applicable <t0 the ‘type of 
project needed to be estimated? 
8. Ease of Use: are the inputs and options used by the 


model easy to understand and specify? 
9. Prospectiveness: does the modei only use information 


lead b] 


that can be fcund before completion of the project? 
d 
Wo. 2eas2tmenvye are rediundant factors and fa 
CS + 


fRef. 3: pe 4/6] 


We will examine the mcedels prasented with resvect to 


- 
> 


Mee abbizcabili2zty of a numpéz> of the above criteria. 


Poems t-rspD moaci, <=ne saitev-Sasiii uncdei ani 
memes) Gace mOcSl previde fairly thorough definitions of 
M@en2hou=S and outputs used. COCOMO orovides aS tnoreougan as 
Beesible definition cr the activities and et. ZOUGd 


odel while not overly constraining either the 
me@el*= generality or a project's flexibility. Rem. oo ce ops 
521] The TRW (SCEP) model uses a standard work breakdown 
Seructure to @ezrine costs included and exciuded in 


GO@OMO estimates come within 20% cf the actual 


developmenz Iigures for the projects in the COCOMO catabase 
Pore ort the time. This means a standard deavietion of the 
eesiduals of roughly 20% of tke actuals. (Phere: 706 O27) 
Bpeenaiysis of the IBM-FSD mcedel reported a standard devia- 
Meme cl 1.7/1 {Ref. 48: p. 5217]. The Bailey-Basili showed 4 
SeopcG@ard deviatton factor cf 1.15 for a fairly uniform set 
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a EE Eee eee = 


7 
| 


TABLE VI 
Factors Used in Various Cost Models 


ee 





| soc, TRW, Putnam, RCA, BOEING, GRC, 
| Group Factor 1965 1972 SUM Doty PRICES 8M 1977 1979 COCOMO 
a eg 
| Sze Source inetructions x x 1 1" x 
{ atroutes «6. Cdiaict instrucvons x x x x 
| Number of rovones x | 
Number of data tems 1 1" 
{ Number of output formats 1" 
| Documentaton " x 
Number of personnet x x 
Program Type PI x x x x x rt 
| atttioutea «= Comp ianity 1 PY K K 
| Language x 1 x x 
Aseuse x x x 1 1 
{ Aoqurad rekaduity x x 
i Computer Time consuant x x x “| x x 1 x 
| attributes  Storaqe constraint x 1 x 1 1 1 
nardware configuragon x x 
i Concurrent hardware development 1 ] x x ri 
| Personnel Personnel capability " x x 
| atinbutes «= Personne! conunury 1 
Hardware expenence x x x 1 x ; x 
Agplicatons expenence x x F 3 x x x 1 
| Language expenence 1 x 1 1 x 
| Provect Tools and techmques 1 1 x 1 1 
| afttrhutes Customer intertace x x 
Roqurements dotiruhon x x 1 
| Requirements volaulity x x r x 
| Senedute 1 1" P| 
Secunty 1 
| Computer access x x 1" x x 
{ Travot/ruhosing x 1 K 
| 


1 aes acates CMD att ee di AD i eee A ae FE ant TE A TED eet) iree a nae EM oo ea pete OD eee CE Qui OED ep, CED 2 


8 prejects at NASA/Goddard [Ref. 46: pp. bi eils The 
meaeclity Of the CCCOMO model with respect to the actual 


Pests Of DLrOyects in the database is better than other 


models‘ estimates of those costs. far de SPOEnlon or the 
database was used tc calibrate the model's parameters. No 


Tuture projects have yet keen completed to evaluate the 


goodness of the model's estimates. 


The Putnam 1978 nodel gives extreme overesti- 
Heres Or <Snall projects and estimates large projects 
reasonapiy well. Putnam's more recently developed SLIM 


eg 





model appears to nave overcome this problem. feet. 89: 9p. 
196 ] The TRW (SCEP) model is still in an experimental state 
and needs more comparisons of SCEP eStimates with actual 


Reo qect results [ Rez. 49: p. 198 j. 
eer OD 7eCc LV. ty 


Mee Shim ana ~2he 


inal Erice-S modsi was extrem jective 
Semoplexz:ty tacto=s — Ref. 49s pe. 198}. The COCO4HO model has 
trie te Meke ‘he Complexity fa 


number of ways. Complexity has peen made 2 module léeval 
instead cf a subsystem or svstem level rating. SOURCES (Ot 


productivity have been separated f 
m 


drivers as much as possibile and 


as yore tec) ee Selle “Sle hele cle Geto oe vy eae! AC Ona eS Cer 
eee fae a Oa @ te a) BOS ey SCcai2 — ‘4 dee Note er be we at oe =- -7? — ee a es oe uk Nw Ce. 

me = pay Doe i oe 2 am ee | | a >| ya = pe ”~ eae ene 
devercped. The TRW (SCzP) Welteiew 2HELUdeS a CONDLSXLcCY 
— Pie Ded — Th An 7s) SS —_ = - - —_ = -_- = ee | =a Fated 
mec TOL. Maomeetloeeh acy =22aangG LS @ Chazac Ssristic or ¢ach 

= = Se ae OS ie -_ = ~ -~ Sh Ay oS ae 
Ret - soCmerarc, and 4 COmplext cy scaic 285 avaliiebie to 
f og 
= aN “ Ba -_— - Sas & = ~ ¥ = = -_ 

_enec no URbdIe COMpicxicy fTeting fer each tyre of unin. 


d. Constructiveness 


The COCOMO modal provides a detailed listing of 
sl 


Ses fecrors affecting the cost of a project 


mee himpact of an individual factor. The mcdel provides 
increased understanding of the software lifecvcle 62 ene 


is 
pes 76C +. Gteters> Pp. 222) The TRW (SCEP) modei provides 3 
meat= =O indicate the degrees of impact cf factors eae 


meciVictces. 
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Ge Deztail 


Models requiring more d2tail usually produce 


more accurate estimaries. 


4. The gathering of greater detail tends to_increase 
people's understanding of the job to oe done; and 

2. if the added detail results in the overall esti- 
Mase being the sum of SOme Smaller individual 
Soule eas, er Culaw Of Large numbers Cends ©O work 
=O daecre2ase Bae = VasaenNce CF ele HS itaso. 
P8ees 2ose. 200] 


GGeO (Omeoua. fesczerecry Cl mMoeadSsls with thea Basic 


COCOMC being used for sarly é¢Stimates and *he Intermediate 
and Déetaiied COCOMO's being used for more detailed and accu- 
rate pce iG 


u a 
estimates. The TRH-Wolverton model is 
macro model and provides detail in phase and activity b 
downs. The 1979 GRC model also provides detail in phase and 


Meeevcuy bESsakadewns. Ret. 3: pe 5223 


ieemmeacy Model has discontinuities at tae neigh- 


memaood Of 10,000 source instructions. Smail differences in 


fever g Can lead to large differences in cest in this arsa. 
meet. 20) Most cost estimating medels, CCCOMO inciuded, 
avoid this problem by providing a number of rating levels 
mee COSt driver attributes dad allowing inzte>polation 


ctetween tnem. 
Je Scope 


Ricmepa-f sop moa el, ch] Mete mocel, the Price=SL 
and tne COCOMO models hav2 ali been déeveloned to on 

Meete-y Of projects and applicacions. Algerit 
modeis in general have a difficult time in g 


= 
Mating ccst for projects under 2000 DSTI. Wheme, 35S p. 523 j 


at 





SLIM and Price-S are well engineered for ease of 
use and understanding. CCCOMO hierarchy ot models makes 
them easy to use and to understand. [Ref. 3: p. 523] 

The TRW (SCEDP) model overest 
ha 


mymet2OnsS well for projects over the fa 


Secos.s On 


@ 
Sua. 


ct 


~~ 
= 


rojects less 


Oo 
J 


@ 
Five person years in total effort, but i 
nge cf 60-2000 


Man montas. 
2. prospectiveness 


Messe Cllst cre mmCOSeenOGdels “mcludirg COCOH#O use 
= 


parameters that can be estimated rather weli at the begqin- 
ning of a project. The oniy exception for COCOMC is the 


Meeerci ley With SiZing the preject. 


j. Parsimony 


moe, NOCe ln 


or 
memmescac..Cal SS =imeaticn of projects. 
effo 


Ret, 487) @be CCCON® 
feet Makes efforts to oniy use factors that have a ccnsic- 
preceoas aitrect on Software froductivity. The mod¢i can be 
meee ored to a particular environment to eliminate redundancy 


Memcractcrs. fret. 3: p. 524] 


Be ESTIMATING COST AND EFFORT: CRITICAL FACTORS 
1. Discussion 


Meme CONGmioge thet What 25 needed in the Field of 


estimating cost and effort in software development projec=s 
2s a reliable, dynamic, transportable nodéel ~ha= is easy to 


Hees Le appears intuitively obvious to us that cost, 2ffor 
and time can be saved by adopting an already existing c 
mM 


e) 
and eriert estimating model to a new environment rather than 


o2 





generating an entirely new model from the ground up. The 
mcedel should be able to estimate cost and effort throughout 
the lifecycle of a software project. Mcst models now only 


estimate through the completicn of testing and the beginning 


of operaticn GavinGge Litzle oF no attention =c  =ne 
Maintenance pnase, The maintenance phase of a sottware 
major portion of rasources 


lifecycle currently ccnsumes the 
x 


so 
eeeeenaes upon a software déevelcpment ertort [Reft. 34: ob. 


Davee ecoWmee Orem st2c¢=- Siculd be dinked <0 “=e 
euecesstul completion of the functions of a proje 


Cc 
Meeliminary werk On a2 particular dasign décision may be weil 


understood by software developers. The kasic steos may 
Port fO> a MajO= physical portion of Ehe etffor<. The 
concluding work done to implement a design decision and the 
Bene eGrating Of AuMmerous as decisions/modules to make the 
System cre Bow eea2est Glfort. The 
model shouid measure eftort 

MeMGemetl Joc) See Ocucec Dus ShOUimMe a2iso relate tnis figure +o 
mee area Of applicability 2£ the lines. nO Set perate, LOSE 
Peeaieed Gt the beginning of th= development cf a désign 
decisicn may be far éasier tc preducs than those at the end 


tistical investigaticn should be used to estab- 
Ss 


S 
i-semci' ps Which mak] 2t possible tc predict c 


mesh re ost 
and 2ffort in terms of cther variabies. Regression teéch- 
hiques are used to perform this ‘ask. Since the number of 
MemeeabicS arrecting the ccst and affort estimated fom a 


given project wiil be many, multiple vreqressi 
Will be necessary. In using observ 
Heememecrcal Squacicn to predict desirad vaiues from given 
values (a procedure known as curve fitting), three problems 
ens se : 


1. cne kind of equation tc be used must be dscided 





2. the best of this type must be fourd 
Sec re «€6©geGOodRess )6of fit of the equation must be 
determined. 
fRef. 51: pp. 431-433 j 
The equation usually chosen results from the inspec- 
tion of the data in most instarces, but the most objective 
Meemeds tor deciding on what curve to fit to numerous points 
should be used. Differences in project estimations will be 


Neos 2 en Vairoumertal Vatiations. ihe 
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software deveiopment and itcm an 2nai 
we have «ried to assimilate those probis 
addressed in the development of a jj 


a 
precdicticn modei. We also endeavored +o alert the nr 


ri 


oi 
o 
a | 


efresh «he experienced reader with the problems he ao 
xpe =e encounter with software cost and effort mn 

moceils. Neoetce Ss) PROLaDLyY DPeantulily apparent to 
at this point, models ara often complex and d 
understand. We recommend to the average manag 
camiliarize himseli with the information presen 
Tesearch and then go and hire someone who is technically 


ccmpetent for specific guidance. fc 31s of any 
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Gompensation to the reader, the authors of this a 
have had es difficult atime as he or she may have had in 
understanding the models presented. 

The key to the success of any such model is the ability 


iT) 


of the estimators to identify variables in the environment 
affecting the estimations and account for these variables in 


the mathematical _ PiaecEeraang 6 COStmand sfreort. The 


3 
(D 
#7) 
cf 


weaknesses with curr 2Nermemag procedures ate sixtolid 
| aS Sl 


ae det 


= 
Ri deter: 
u 


Be 
. 


Beebe ce@ OF a@cttention <= ce or the develcpers 

6. lack of attention tc the management erfort and the 
Mao | See Manage... 

A heperul avenue cf research that may provide more reli- 

able ¢stimates is Silver's method Geter ls. Fuceured 


Meelne COSt and Srifort in Sottware daveionoment projects in 
Peevate industry is consideration of =he management effort 
and =he project manager. Unless a sound team is organized 
Mewet 2 Strong isceader, ali estimations of projec* cost and 


Beojec=s has already been influenced by the introduction of 
various <ools and the concept cf software development envi- 
ronments. Programmer productivity is expected te increase 
Pemeeocis are refined and better integrated with one another. 
What is ¢specially exciting in the long ‘t¢rm future of 
Pegagreamm=ing, chat is, orogramming into the early decades of 
Peewee (St CENtTULY, is =h2 concept of automatic programming. 
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The texrm ‘automatic programming’ has been used for many 


years to rerer z the precess by which an executable 
progrem _may _ be produced 5S) jay NON DEOeGe4 tae 1 
SocmieiecaulLens Of ©he task to be pertormed. Over the 


lenger tern, it will be possible for pregrammers to 
Sscocc fUnning Ppecdrams by providing a specification of 
PecGgeatmrimerl ons anc OUEpPUts, withoat having to proceed 
Ween cmG@etelL=a PE@Gram design OF with the production of 
eoqes HReft. 525 p. 204] 


j 


The present differences b application pregzrammers 


= n 
and system programmers are likely <o incr2ase. Syvsten 
Beogcroammers deal with the details of «ke low level computes 
Vv mn 


Wnereas applicaticn programmers deal with the deveicrermenz of 


Seodrams =O mest user speci fications. Wa Eas ane ccapered 
advent cf automatic programming, =H} uSer—-cperatc= will 
memay OU. Whee 9 we AOwW CCnSider progltamming 4&5 he interacts 
Meng Ne-iral languac?] with the ccmputer. Pie ee ean os 


programmer will increasingly be involved with understanding 
Mee hmeecsS OF Ppart~i:cular adplication areas for software, 
Peete ese ams 1980494 2i0n System applications, their 
Mmercomat_On céguirements, Cac an iz 

sonnel makeuc. A eCumNPee ee acetic ens USED -OU Ste lOEs 
GE =he companies in understanding th 
Bse “Feeds “inte specific requests to be autcmatically 
proqramméed py the computer into an afiective application 
sortware progran. 


were Gan He Seen that the nature of prograrmminre 

programmers is certain to change, and that an increas 

Sface Of Woat we NOW term Pregramming will be carried out 

Me25-Operatcrs, wno will nave tools at their disposal ti 

permit them tO interact naturally with a computer system a 
a 


}4-su 


J 


Hi 


Bescirty their squests. meres souly Wien such tools 

Beovicged that the exponential growth in ‘the number 

programmers and the cost of software can be slewed and = 
attention may be deveted to making the greatest possi! 
Bemeotitctal use of the computer. fRef. 52: p. 205 
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